Nonetheless, the automatic versioning makes sure that every build will create a unique version by appending `<major>.<minor>.<patch>` with a buildversion (we use a timestamp) and optionally the commitId.
In order to represent this version also in the version control system the new unique version will be pushed with a dedicated tag (`<tagPrefix><major>.<minor>.<patch><unique extension>`).
Depending on the build tool used and thus the allowed versioning format the `<unique extension>` varies.
**Remarks:**
*There is no commit to master since this would create a perpetuum mobile and just trigger the next automatic build with automatic versioning, and so on ...
*Not creating a tag would lead to a loss of the final artifact version in scm which often is not acceptable
*You need to ensure that your CI/CD system can push back to your SCM (via providing ssh or HTTP(s) credentials)
*The new version will NOT be written as tag into the SCM but it is only available in the corresponding CI/CD workspace
* IMPORTANT NOTICE:Using the option `cloud_noTag` should not be picked in case you need to ensure a fully traceable path from SCM commit to your build artifact.
### 2. Pure version `<major>.<minor>.<patch>`
This pattern is often used by teams that have cloud deliveries with no fully automated procedure, e.g. delivery after each takt.
Another typical use-case is development of a library with regular releases where the versioning pattern should be consumable and thus ideally complies to a `<major>.<minor>.<patch>` pattern.
The version is then either manually set by the team in the course of the development process or automatically pushed to master after a successful release.
Unlike for the _Continuous Deloyment_ pattern described above, in this case there is no dedicated tagging required for the build process since the version is already available in the repository.
Besides the `buildTools` provided out of the box (like `maven`, `mta`, `npm`, ...) it is possible to set `buildTool:custom`.
This allows you to provide automatic versioning for tools using a:
#### file with the version as only content:
Define `buildTool: custom` as well as `filePath:<path to your file>`
**Pleasenote:** `<path to your file>` need to point either to a `*.txt` file or to a file without extension.
#### `ini` file containing the version:
Define `buildTool: custom`, `filePath:<path to your ini-file>` as well as parameters `versionSection` and `versionSource` to point to the version location (section & parameter name) within the file.
**Pleasenote:** `<path to your file>` need to point either to a `*.cfg` or a `*.ini` file.
#### `json` file containing the version:
Define `buildTool: custom`, `filePath:<path to your *.json file` as well as parameter `versionSource` to point to the parameter containing the version.
#### `yaml` file containing the version
Define `buildTool: custom`, `filePath:<path to your *.yml/*.yaml file` as well as parameter `versionSource` to point to the parameter containing the version.
description:Jenkins 'Username with password' credentials ID containing username/password for http access to your git repository.
type:jenkins
- name:gitSshKeyCredentialsId
description:Jenkins 'SSH Username with private key' credentials ID ssh key for accessing your git repository. You can find details about how to generate an ssh key in the [GitHub documentation](https://docs.github.com/en/enterprise/2.15/user/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent).
description:Additional buildTool targets where descriptors need to be updated besides the main `buildTool`.
longDescription:|
**Onlyfor versioning types `cloud` and `cloud_noTag`.** This parameter allows you to propagate the version to other build-tool specific descriptors.
If the parameter [`additionalTargetDescriptors`](#additionaltargetdescriptors) is not defined the default build descriptors are used.
One example is to propagate the version into a helm chart.
This can be achieved like
```
steps:
artifactPrepareVersion:
additionalTargetTools:
- helm
```
scope:
- PARAMETERS
- STAGES
- STEPS
possibleValues:
- custom
- docker
- dub
- golang
- gradle
- helm
- maven
- mta
- npm
- pip
- sbt
- yarn
- name:additionalTargetDescriptors
type:"[]string"
description:Defines patterns for build descriptors which should be used for option [`additionalTargetTools`](additionaltargettools).
longDescription:|
**Onlyfor versioning types `cloud` and `cloud_noTag`.** In case default build descriptors cannot be used for [`additionalTargetTools`](additionaltargettools) this parameter allows to define a dedicated search pattern per build tool.
For each entry in [`additionalTargetTools`](additionaltargettools) a dedicated entry has to be maintained.
You can use either a file name or a glob pattern like `**/package.json`.
For `helm` the default value is `**/Chart.yaml`, thus typically no adaptions are required.
description:"Defines a custom path to the descriptor file. Build tool specific defaults are used (e.g. `maven: pom.xml`, `npm: package.json`, `mta: mta.yaml`)."
