Falkor operations commander
npm install @falkor/falkor-commanderfalkor-commander project is a standalone npm command-line application written in strict ES6 TypeScript. It is a plugin based task runner / -sequencer using the @falkor/falkor-library to make everyday devops tasks more approachable, friendly, and secure in the terminal for non-technical people.
PATH:
$ npm install --global @falkor/falkor-commander
`
Usage
There is an up-to-date testing repository at falkor-plugin-example to demonstrate framework capabilities, which you can use to test features, or as a boilerplate for your own task sequence.
$3
Usage:
`
falkor-commander [(--scope ) | (--path )] [(--keyword )] [(--registry )] [...] [(-- ...)]
falkor-commander [(-s ) | (-p )] [(-k )] [(-r )] [...] [(-- ...)]
falkor-commander (-v | --version | -h | --help)
`
Options:
- -v or --version: Show version and exit
- -h or --help: Show help and exit
- -s or --scope : The scope to look for plugins under node_modules (default: @falkor)
- -p or --path : Explicit directory to look for plugins in (overrides scope setting)
- -k or --keyword : The keyword to look for in plugin candidates' package.json (default: @falkor-plugin)
- -r or --registry : Registry to use when searching for plugins at fresh install (default: https://registry.npmjs.org)
- : Treat all positional arguments as buffered task IDs
- -- : Treat all positional arguments after double dash as buffered input
Task Specific Options:
It is possible to forward command line arguments to individual tasks exposed by plugins. To compose such option, one has to use the task's escaped ID (spaces replaced with dashes, all lowercase) after double dash, so eg. Example Task becomes --example-task.
The value of such an option is similar to command line options, only using # instead of -, so building on the previous example eg.:
`
--example-task "##debug #V #a10 ##key key-value positional-value ## extra-value"
`
This will be parsed by minimist after transformation, and passed to the specific task's run method as:
`javascript
const argv = {
debug: true,
V: true,
a: 10,
key: "key-value"
_: ["positional-value"],
"--": ["extra-value"]
}
`
If for some reason the # character is reserved in your workflow, it can be substituted with an other special character starting the value with the ": sequence:
`
--example-task ":$ $$debug $V $a10 $$key key-value positional-value $$ extra-value"
`
Further Development
The project uses the @falkor/falkor-bundler module to compile sources. To clone the repository and compile falkor-commander one can use the commands:
`
$ git clone --branch develop git@github.com:theonethread/falkor-commander.git
$ cd falkor-commander
$ npm install
$ npm run [ debug | release ]
`
> _SEE: "scripts" entry in package.json for further reference._
> _NOTE: Compiling the develop sources might need locally linked develop versions of downstream modules:_
>
> - _@falkor/falkor-library_
> - _@falkor/falkor-bundler_
>
> _SEE: npm-link for further reference._
$3
By default the falkor-commander project ships with a pre-compiled man page when installed on Unix-like operating systems. The manual was created by converting the file man/man.md.
To recompile the manual, make sure that Pandoc is installed, and present in the PATH, then run:
`
$ npm run man
`
$3
The project uses prettier for code formatting and cspell to avoid general typos in both sources and documentation - it is advised to install these packages as extensions in your IDE to prevent CI errors beforehand. To lint the project run:
`
$ npm run lint
`
> _SEE: .prettierrc and .cspell.json for further reference._
- To fix formatting issues run $ npx prettier --write . This will overwrite the file with the default formatting applied locally, so then you can review the changes in git and ensure those did not affect production artifacts.
- To fix spelling errors run $ npx cspell lint --wordsOnly --unique --gitignore --exclude .git * . for details, and either make the fixes in the sources listed, add cspell favored comments, or extend the project-wide .cspell.json accordingly.
$3
Release sources can be found on the master branch, this one always points to the latest tagged release. Previous sources of releases can be found using git version tags (or browsing GitHub releases). Released packages can be found on npmjs.
The repository's main branch is develop (due to technical reasons), this holds all developments that are already decided to be included in the next release. Usually this branch is ahead of master one patch version (but based on upcoming features to include this can become minor, or major), so prepared external links may yet be broken.
The feature/* branches usually hold ideas and POC code, these will only be merged into develop once their impact measured and quality meets release requirements.
> _The project uses SemVer, git tags are prefixed with a v character._
$3
The workflows can be found here.
#### Continuous Integration
Automatic builds are achieved via GitHub actions, CI will make nightly builds of the develop branch (using Ubuntu image), and test master` when there is a pull request, or commit on it (using Ubuntu - Win - MacOS image matrix).