metadata: name: artifactPrepareVersion aliases: - name: artifactSetVersion - name: mavenExecute - name: setVersion deprecated: true description: Prepares and potentially updates the artifact's version before building the artifact. longDescription: |- Prepares and potentially updates the artifact's version before building the artifact. The continuous delivery process requires that each build is done with a unique version number. There are two common patterns found: ### 1. Continuous Deployment pattern with automatic versioning The team has full authority on `..` and can increase any part whenever required. Nonetheless, the automatic versioning makes sure that every build will create a unique version by appending `..` with a buildversion (we use a timestamp) and optinally 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 (`..`). Depending on the build tool used and thus the allowed versioning format the `` 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) **This pattern is the default** behavior (`versioningType: cloud`) since this is suitable for for most cloud deliveries. It is possible to use `versioningType: cloud_noTag` which has a slighly different behavior than described above: * 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 `..` 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 `..` 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 descibed above, in this case there is no dedicated tagging required for the build process since the version is already available in the repository. Configuration of this pattern is done via `versioningType: library`. ### Support of additional build tools 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: ` **Please note:** `` need to point either to a `*.txt` file or to a file without extension. #### `ini` file containing the version: Define `buildTool: custom`, `filePath: ` as well as parameters `versionSection` and `versionSource` to point to the version location (section & parameter name) within the file. **Please note:** `` need to point either to a `*.cfg` or a `*.ini` file. #### `json` file containing the version: Define `buildTool: custom`, `filePath: