martinohmann / kickoff Goto Github PK
View Code? Open in Web Editor NEWKick off projects from skeleton directories
Home Page: https://martinohmann.github.io/kickoff/
License: MIT License
Kick off projects from skeleton directories
Home Page: https://martinohmann.github.io/kickoff/
License: MIT License
Repository names should not contain colons or spaces as fully qualified skeleton names are of the form <repo-name>:<skeleton-name>
. Allowing spaces in repository names would impede the UX of the CLI as users need to explicitly quote things.
Adding a relative local repo will not resolve to an abspath. This will break when changing dirs.
Right now, every component (e.g. the repository
package) just logs stuff, maybe with some fields attached.
For better visibility from where logs are generated, a field component
should be added on the package level.
Multiple package may use the same component field value if they are related.
Right now, for most of the output that is meant to be human readable log.Info
is "abused". This is especially true for the output of kickoff project create
.
It would be nice if kickoff project create
would create output in a human readable form that is not backed by a logger.
Proposal: only print logs of level >= warning to stderr and change the places that print stuff using info level for the user to proper output to stdout. log.Info
and log.Debug
can still be used for information that can be enabled using --verbose
or --debug
flags respectively.
Skeletons should be able to inherit from parents. .kickoff.yaml
of a skeleton could include a parent
field which references one or multiple parents. The skeleton's config and files are then merged on top of the parent's config and files before creating a project.
This makes it possible to reuse common files and templates, e.g. README.md.skel
or CI configs/Makefiles, across skeletons that bootstrap similar projects.
When a remote repository is removed via kickoff repository remove <name>
the locally cached checkout should be removed as well.
Right now this has to be cleaned manually or (for all repos) via kickoff cache clean
.
Hi, thanks for a great project! I was wondering if it is possible to add a repository using ssh
instead of https
? I.e.
kickoff repository add myskeleton [email protected]:martinohmann/kickoff.git
Running this results in
error: invalid repo URL "[email protected]:martinohmann/kickoff.git": parse "[email protected]:martinohmann/kickoff.git": first path segment in URL cannot contain colon
My use case is that I have a private repository for skeletons that is only cloneable using ssh
.
If the default config.yaml
file does not exist, kickoff repository add
fails with
error: open : no such file or directory
This might also affect other commands and needs to be fixed.
It should be possible to conditionally render *.skel
template files. The most flexible solution that would not require any additional configuration would be to only write rendered templates to the project output dir that are not empty.
Then we can conditionally include/exclude files like in the following example.
Given a template file someconfig.yaml.skel
with content:
{{- if .Values.someconfig.enabled -}}
---
some:
config: value
{{- end -}}
In .kickoff.yaml
of the skeleton set a default:
---
values:
someconfig:
enabled: false
By default the file will render to a content length of zero and would thus be ignored.
Users can then enable the file by passing --set someconfig.enabled=true
to kickoff create
.
Add a simple init command that creates a new skeleton with a sensible .kickoff.yaml
and maybe an example README.md.skel
to get users started with templating a skeleton quickly.
The kickoff skeleton create
command is relatively useless as it currently allows to create skeletons anywhere on disk. This may include locations outside of skeleton repositories known to kickoff.
It should be changed to require the name of a local skeleton repository where to create the new skeleton. Attempting to create a new skeleton for a remote repository should fail.
Right now Git operations and API requests do not have timeouts set which makes kickoff commands hang under certain circumstances.
Timeouts should be added and we should also think about what to do when we run into timeouts. Fall back to local cache if available? Fail? Proceed without the resource (e.g. create project without a license and warn the user about it if license fetching times out)?
default
repository https://github.com/martinohmann/kickoff-skeletons
.Right now, most of the errors are just printed without much context for the user. The should be enriched with better context so users how what to do.
Due to the recent output changes some output examples in the docs are not accurate anymore.
Some that come to mind:
skeleton show
Repository created
It's tedious to always specify --dry-run
and/or --force
and most of the time it is forgotten which leads to accidental project creation with the former and annoying errors with the latter.
Instead remove both flags and change the behaviour in the following way:
--yes
flag which can be set to automatically acknowledge these questions.This requires some bigger changes to the project creation logic as it needs to produce a plan which can be reviewed and applied after the user acknowledged it (similar to terraform plan/apply
).
This should be done before implementing #81.
When creating a new local repository via kickoff repository create
save it to the repository config so that it can be used immediately (something like internally calling kickoff repository add
).
Add a --skip-file
flag to the project create
command to selectively skip files that should not be written to the target dir. If a filepath is a dir, the whole dir should be skipped.
This makes the --allow-empty
logic obsolete. The flag should be removed.
Right now template authors and users can define arbitrary values for usage in skeleton templates.
While this approach is very flexible it has a couple of drawbacks:
If values are replaced with typed params we can make them more useful:
kickoff skeleton show
can display more useful information about skeleton parametersOne challenge here is to figure out how to make this work with skeleton composition where multiple skeletons define one (or more) parameters with the same name and possibly different types or semantics. Merging here does not seem to be the most sensible thing to do. A possible solution would be to avoid merging parameters at all and instead always only pass parameters from the skeleton that a template file originated from to the template file. This would avoid conflicts and make the behaviour more predictable as it does not depend on the order in which skeletons are merged on top of each other.
The core logic is currently implemented in methods on the cmd.CreateOptions
struct which is not the best place as it should only handle input validation and defaulting. Its Run
method should only pass the final input to a type that executes the business logic.
GitHub provides .gitignore templates via their Developer API. Add an option to automatically include a gitignore template when creating a new project. This is basically equivalent to the logic used to include a license.
To be able to use kickoff
for in-project features (not a new project, but just a set of files), it would be handy to be able to define placeholders, for example in config files.
Example use case:
Given that I have a config file, if I want to bootstrap a set of files, and one of them needs to be included in a config file, it's right now not possible.
If I could define a placeholder in the config file that kickoff
interprets as don't replace, make sure all values of a list are there
, `kickoff could be also used for feature creation.
Example file:
# config/services.yaml
imports:
# kickoff:block:<my_identifier>:start
- { resource: services/kickoff_created_config1.yaml }
- { resource: services/kickoff_created_config2.yaml }
# kickoff:block:<my_identifier>:end
By placing an end
marker automatically after the inserted values, kickoff
would know what block to append on consecutive runs.
Is it possible to configure the default branch when initializing git on project creation? It looks like master
is always used, even if
git config init.defaultbranch
outputs main
.
The name skeleton-go
does not fit anymore as it is only written in Go but can create projects for other languages as well. The new name should be chosen with this fact in mind.
The license texts are pulled from the github API which imposes rate limiting on unauthenticated requests.
One solution would be to make use of the GITHUB_TOKEN
env variable if present and authenticate using that.
Another solution would be to fetch the licenses once and cache them in the user's local cache dir and only re-request them after a longer period (e.g. 1 week) or on a cache miss.
Skeletons could be managed in community repositories so that they can be shared between users. For that to work it needs to be possible to point the skeletons-dir
to a remote repository (or even manage a list of remote repos in the local config).
Repos could then be cloned if not present, or pulled if present in the user's local cache.
Add a flag to kickoff project create
(maybe -i
/--interactive
?) to interactively provide creation options (e.g. select license/gitignore from list, edit values via editor). Similar UI like kickoff init
.
Alternatively this could be the default behaviour when the user does not provide any arguments.
The interactive prompts should only ask for input for options that were not explicitly provided via flags.
It does not reflect the current state of the CLI and needs to be updated.
Needs to be updated in README.md
and docs/index.md
.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.