martinohmann / kickoff Goto Github PK

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.

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.

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.

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.

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 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:

• no validation of user input, unexpected value types could produce weird template rendering results or even errors
• editing raw yaml during project creation is not very ergonomic
• since values are untyped and do not follow a schema it's not feasible to provide the user with a mechanism to set them interactively

If values are replaced with typed params we can make them more useful:

• typed params can be validated
• can include a description and custom validation rules. configuration format could look similar to cloudformation parameters: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html
• during interactive project creation a prompt can be generated for each parameter that can be set
• kickoff skeleton show can display more useful information about skeleton parameters

One 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.

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:

• Produce a project creation plan which can be printed.
• Prompt the user if he/she wants to apply this plan. Print a warning when the plan would write a project into an existing directory.
• Add a --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.

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.

• kickoff should not automatically add the default repository https://github.com/martinohmann/kickoff-skeletons.
• commands involving repos should return a helpful example when no repositories are configured to show how to do that.

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.

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)?

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.

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.

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.

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.

Adding a relative local repo will not resolve to an abspath. This will break when changing dirs.

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).

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.

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.

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.

Due to the recent output changes some output examples in the docs are not accurate anymore.

Some that come to mind:

• project creation output
• skeleton/repo list
• skeleton show
• success messages, e.g. Repository created

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.

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.

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 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.

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.

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.