artifactSetVersion: only create tag without creating a commit

[marcusholl]

Currently artifactSetVersion adjusts the version,

• adjusts the version
• creates a commit containing the files modified by adjusting the version
• creates a tag and
• pushes that tag.

It is possible to skip writing the commit (property commitVersion). But with that not only committing the changes is dropped, but also writing and pushing the tag.

It should be possible to simply write a tag without prior commit. This means the tags sits directly on the commit being built. In this case we have local changes when the tag is created. There is no need to have the local changes in the commit history.

It should also be possible to write the tag without directly pushing it and to push the tag later in the same pipeline run.

Use case: the build is performed on the same build server where the version is changed. Hence there is no need to push the commit with the changed version. The tag should be pushed later after e.g. a deployment of the artifact(s) created by the build was successful.

[marcusholl]

See #1028

[OliverNocon]

I would suggest to have a discussion about the use cases and then decide how to proceed with all people interested. We can then document the outcome here. Especially in the light of moving to golang implementations we should rather invest there IMO instead of further complicating this step which anyway is already pretty complex and hard to understand for users.

[OliverNocon]

Following versioning patters are currently seen as the typical patterns used by teams. From my POV both make absolute sense:

1. Continuous Deployment pattern with automatic versioning

The team has full authority on <major>.<minor>.<patch> and can increase any part whenever required. Nonetheless, the automatic versioning makes sure that every build will create a unique version by appending <major>.<minor>.<patch> with a timestamp and the commitId.

In order to represent this version also in the scm the new unique version will be pushed with a dedicated tag (build_<major>.<minor>.<patch><unique extension>).

There is a default for the version extensions provided which can be build-tool specific. In addition it is possible to customize the extension.

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

This pattern is the recommended default for Cloud deliveries within SAP.

2. Pure Semver <major>.<minor>.<patch>

This pattern is often used by some teams that have no fully automated procedure, e.g. delivery after each takt. Another typical use-case is development of a library where the versioning pattern should be consumable and thus ideally complies to Semver <major>.<minor>.<patch>

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.

In this case there is no dedicated tagging required for the build process since the version is already available in the repository.

This is also a typical pattern used.

General Assumptions

In line with the best practices for Continuous Delivery and the findings by e.g. the State of DevOps reports (documented for example in the book "Accelerate") "Project "Piper" takes following assumptions about the practices, e.g.:

• Trunk-based development
• Loosely coupled architecture
• Test automation
• Deployment automation
• Shift left on security
• Empowered teams
• Continuous Integration
• Version control