SKA
SKA is a "skaffolding" tool that allows you to expand folders based on local or remote blueprints (GitHub and GitLab
hosted)
Additionally, you can update your folder structure from the upstream blueprint to onboard new changes that are
maintained centrally and added overtime to upstream.
SKA is designed for simplicity and quick usage. If you want to integrate SKA capabilities in your app or framework
you can leverage the package under pkg/
.
SKA in action
Get Started
SKA is distributed via Homebrew, so you can install it with the commands below:
brew tap gchiesa/ska
brew install ska
How To Use
SKA is very simple to use. Just run create
with the upstream blueprint you want to use. See below example for
scaffolding a golang command line tool:
ska create --blueprint https://github.com/gchiesa/ska-golang-cli-template@master --output ~/workspace/myNewApp
This will load the remote template, collect the required variable via Terminal UI and create the project for you.
In the root of the project you can find the SKA configuration file .ska-config.yml
that will keep track from now
on of state and upstream reference.
When you want to update your project, just use:
cd ~/workspace/myNewApp
ska update --path .
you can modify the variables or accept the current version. Your project will be updated based on latest changes in
the upstream blueprint.
More information are available with ska --help
.
Concepts and Templating
Upstream Blueprint
This is the typically centrally maintained template that everyone can use to expand its own folder structure. You
can specify the blueprint both locally and remotely with specific URIs:
- file:// for local blueprints. E.g.
file:///Users/gchiesa/git/ska-example-template
- https:// for GitHub or GitLab (soon) blueprints. You can optionally pin a specific reference (tag or branch with
the
@
)
symbol. E.g. https://github.com/gchiesa/ska-example-template@v1.2.3
Update from upstream
Whenever the upstream template changes, you might want to onboard the changes yourself. This is natively supported
by SKA, by offering a simple update
command with not additional arguments required.
See How To Use section for more information.
Upstream Template Language
SKA currently fully supports primarily Go Template framework for templating your upstream blueprint.
Moreover, in addition to Go Template you can use the extensions offered by Sprig functions
If you are not familiar with Go Template have a look to this simple how-to.
NOTE: SKA supports also a Jinja2 like engine (use the --engine jinja
argument) that will make your life easier
when you need to deal with native go code. However, the function set is limited. The support is based on Pongo2
project.
Templating with partial sections
SKA offers the capability to manage only part of files.
This is generally useful to keep only a specific part of the file centrally managed by the upstream blueprint and
let the user change the rest of the file. See as example
the codecov.yml
here
This is achievable with the named partials, a type of block you can use in the SKA template.
For example, if we want to have only a section of a larger file managed by SKA we can use the approach below:
# this is an example YAML and we want SKA to only manage the section `key4`
---
root:
key1: value1
key2: {{.notManaged}}
key3: value3
# ska-start:key/4
key4:
subkey: "{{.appName}}"
subkey2: value2
# ska-end
key5: value5
by using the ska-start:<blockName>
and ska-end
tags, you instruct SKA to only process the block and leave the
rest of the file as it is.
This is quite useful for files where only a part should be centrally managed and the rest will be customized by the
user, after the initial creation.
Template variable collection via Terminal UI
While developing the blueprint, you can configure SKA to collect the variables via Terminal UI.
To do this you need to create on the root of your blueprint folder a special file .ska-upstream.yaml
. The file is a
simple YAML file with the following structure (see example with comments):
# list of path that will be ignored in the blueprint
# typically it's wise to ignore `.git` and `.idea` (and your preferred IDE) since you might use
# the blueprint not only from remote but also from your local filesystem
ignorePaths:
- .git
- .idea
# list of path (can be templated) that will be pre-populated in the final ska-config
skaConfig:
ignorePaths:
- "idea/*"
- test-file-to-be-ignored-{{.testFileName}}.txt
- "*.ignored"
# this is the section that SKA will consume to generate the input form.
# each input supports the following information:
#
# * placeholder: the name of the variable you used in the template blueprint
# * label: the label used in the form
# * help: the help inline to be presented in the form for that specific field
# * regexp: a validation regexp that will be used to specify the set of accepted characters (NOT A ENTIRE PATTERN VALIDATION)
# * default: the default value you might want to present in the form
inputs:
- placeholder: githubRepo
label: Github Repository
help: The url of the github repository e.g. https://github.com/org/repo
regexp: "^[a-z0-9-/:.]*$"
# ... other inputs
SKA will check if the file is present and if yes, then a Terminal UI interface will be used to collect the inputs.
The interactive Terminal UI can be disabled with --non-interactive (-n)
command line argument.
Example template
Check this example golang cli tool template: https://github.com/gchiesa/ska-golang-cli-template
Contribute
You are more than welcome! please have a look to CONTRIBUTING.md
Credits
SKA is made with 💙 by Giuseppe Chiesa as exercise to learn a bit better GoLang.