changelogs
All releases of Ontrack are listed at https://github.com/nemerosa/ontrack/releases.
The changelog below lists only major changes.
The 4.11 release introduces a couple of major changes, some visible, some in the background.
Starting from 4.11, some features are hidden and are available only if you provide a signed license to Ontrack. Please contact the Ontrack support on how to get and install a license.
Licensed feature
Ontrack now offers the possibility to go beyond CI and to deal directly with deployments, without using promotions or other means to simulate this.
Please contact the Ontrack support on how to get a demo.
Workflows are a way to perform some orchestration of tasks upon some events happening in Ontrack. In 4.11, the workflow engine has been reviewed for better performances and true parallelism.
The promotions in the build page are now displayed horizontally instead of vertically. This allows for a better support for extra features like deployments.
- the GraphQL
WorkflowInstance.contextfield has been replaced byWorkflowInstance.event - the type of the
idfield for all project entities has been changed fromInt!toID!- the only impact is that these fields are now returned in the JSON as strings instead of numbers ("12"instead of12)
- different warnings in the Next UI were persistent. You can now dismiss them.
In the build page, the promotion runs now show how many notifications for each status (success, running & errored) have run for them. This allows the tracking of any event linked to these promotions. Clicking these notifications goes to the promotion run page, where more details are available.
In the branch page, the same kind of information is displayed for each build: the number of notifications for each status.
Clicking such an annotation goes to the build page, where the notifications linked to this build are now also displayed.
In the notification recordings, it's now possible to access a page listing all properties of the recordings, as well as expanding its details in the table.
On this page, as well as in the expanded rows, the subscription link (if applicable) has been refactored for more clarity. The main event responsible for the notification (like a link to a promotion run) is also available.
The subscription source and the corresponding triggering event is now also displayed in the workflow list & details.
Overall, this allows a complete bidirectional traceability between all elements participating into a notification: the entities, the subscriptions, the notification itself, any workflow, etc.
Before this version, an auto-versioning configuration could only edit one file (or a list of files having the same format) and any special case had to be dealt with using some kind of post-processing. This could be both artificial and cumbersome in some simple cases.
Starting from 4.10, an auto-versioning configuration, additional to its main or default path, format, etc., can define additional files or sets of files to be adapted as well.
For example:
configurations:
- # ...
targetPath: "gradle.properties"
targetProperty: "one-version"
additionalPaths:
- path: manifest.toml
property: global.oneVersion
propertyType: toml
versionSource: metaInfo/rpmVersionIn this case, we want the auto-versioning to:
- update the
one-versionproperty of thegradle.propertiesfile using the version of the build having been promoted - update the
global.oneVersionproperty of themanifest.tomlfile, but this time using therpmVersionmeta-information of the build having been promoted
Both changes will be part of the same PR.
Post-processing is still possible and would be run after all changes have been applied first (default path & additional paths).
If you're using the ontrack-jenkins-cli-pipeline and want to setup additional paths, you need to use at least its version 4.10. Prior versions will keep working with Ontrack 4.10 but you won't be able to setup these additional paths.
When auto-versioning requests are processed, the source branch (the one containing the actual version update and any post-processing result) is always created anew, deleting any previous branch.
In the auto-versioning configurations, the versionSource parameter is used to control how the "version" is extracted from the build having been promoted.
There is a new link version source having the following format, allowing to get the version from linked builds:
link/<project>[/<qualifier>][-><sub version>]
Examples:
-
link/dependencyto get the version of a build linked to the promoted build for thedependencyproject -
link/dependency/my-qualifierusing a qualifier
The linked build can have its own version source after the -> separator and links can be chained:
link/dependency/my-qualifier->link/component->metaInfo/rpmVersion
This allows the launch to auto-versioning for components linked to the life-cycle of an aggregator component.
Notifications linked to a promotion can now be seen in the promotion run page:
While the auto-versioning processes could always be followed using the "auto-versioning audit" page, it was always difficult to track why some auto-versioning took place or most importantly, why they did not.
Starting from 4.9.6, in the Ontrack Next UI, you can track this information at several levels.
When going to the details of a promotion, you can see all the possible auto-versioning processes that have or could have been requested.
For each of them, you can access the potential target branch and its auto-versioning configuration.
You can immediately see the status of the auto-versioning request (if it was actually requested, and if yes, its status and also a link to its detailed audit).
In the promotion level page, you see a more static view of the potential auto-versioning targets:
This gives you a view of what are the eligible branches for the auto-versioning based on this promotion.
The promotion run page, while present in the legacy UI, was still missing in the Ontrack Next UI. You can now access it from:
- the history of runs in the promotion level page
- the promotions in the build rows in the branch page
- the history of promotions in the build page
Finally, the auto-versioning audit now contains a link to the actual promotion run which triggered it. From there, as mentioned above, you can track the reasons of why the auto-versioning was requested in the first place.
The branch auto-versioning configuration is now displayed in its own page. It can be accessed either from the branch information (the (i) icon at the bottom right corner) or through the Tools dropdown. Note that this view replaces the simple YAML dump which was previously displayed in the branch information panel. The auto-versioning configuration can now be deleted by authorized users (or parts of it).
The Promotion Level page now displays the list of branches that will be targeted by auto-versioning whenever this promotion is granted to a build:
Version 4.9 introduces names for the subscriptions. Before, subscriptions were anonymous, leading to issues when modifying them (subscriptions were often duplicated).
When migrating to 4.9, subscription names will be automatically generated, but the recommendation is to name them properly, using the UI or the API.
If using the Ontrack Jenkins pipeline library, you can upgrade to version 4.9.
As of 4.x, the subscription name remains optional for backward compatibility and will be generated if not provided. It'll become required in Ontrack 5.x.