@@ -171,3 +171,26 @@ Each template capable of publishing (versioned) packages, shall implement it acc
Decorelating the publish job from the release process ensures that all publish-capable templates will always take care of publishing their own package(s),
whichever the technique that was used to trigger the release (manual, semantic-release or any other alternative).
## Command-line options: template or user controlled?
Most of _to be continuous_ templates implement their functionalities by calling command-line applications, that can usually be configured with command-line options (possibly in addition to other techniques, such as configuration files and/or environment variables).
It is highly important - when designing your template - to separate the command-line options in two categories:
| Who controls the option? | Description | Guidelines |
| :lock: **template controlled** | Options you (as the template developer) want to control because they are part of the proper implementation of the template | • Must be **enforced** and **hard-coded** in your job implementation. |
| :unlock: **user controlled** | Options that the user will be allowed to customize (project specific preferences) | • **Documented** and **customizable** by the user.<br>• You should decide [what are the **good default**?](#sensible-defaults)(_90% of the time, the tool defaults are fine_). |
Example with a unit-testing tool:
1.**template controlled** options:
- enforce human readable report in the output console,
- enforce JUnit report with controlled report path (to ensure the proper [GitLab integration](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportsjunit))
- enforce code coverage with controlled report format and path (to ensure the proper [GitLab integration](https://docs.gitlab.com/ci/yaml/artifacts_reports/#artifactsreportscoverage_report))
- fail the program execution when tests are failing
2.**user controlled** options:
- the tests to launch, as a glob pattern (with TBC default `**/*.test.xyz`)
