v4 release notes

V4 release notes

All releases of Ontrack are listed at https://github.com/nemerosa/ontrack/releases.

The changelog below lists only major changes.

4.13

Version 4.13 introduces the Yontrack name and will be the last 4.x version before the major 5.x version.

4.13.23

When using Jira Cloud and using service accounts (not linked to any user) for automation, the API URL is not the same as the UI URL.

The Jira API URL can now be specified separately either in the UI configuration or in Casc:

ontrack:
    config:
        jira:
            - name: jira
              url: https://jira.nemerosa.com
              apiUrl: https://api.atlassian.com/cloudid
              user: ...
              password: ...

In most of views, when a link to a build is displayed, the display name (the value of the release property), when available, is now displayed instead of the build name..

4.13.20

New createValidationRunByRelease mutation which allows to create a validation for a build using only its project name and its release label.

For example:

mutation {
    createValidationRunByRelease(input: {
        project: "yontrack",
        buildRelease: "4.13.20",
        # ...
    }) {
        # ...
        errors {
            message
        }
    }
}

This can be convenient when external components call Yontrack to perform a validation in one call and knowing only the project and the release.

4.13.19

The "test summary" validation data type has a new failWhenNoResults option which sets the validation to fail if there are no tests.

It's set to false by default, so that the old behaviour is maintained (the validation is marked as passed if there are no tests).

The Ontrack CLI (0.13.0) and the Jenkins pipeline steps (4.13) have been adapted to take into account this new option.

4.13.18

Build links between two projects can be qualified and this can be also done for the links created by the auto-versioning check. While the qualifiers were correctly set for these links, they were not displayed in the auto-versioning audit.

The GitHub auto-versioning post-processing workflow example has been updated in the documentation for more simplicity.

When configuring the GitHub auto-versioning post-processing at branch level, you can now override more than the workflow name, but also the repository and the branch.

4.13.17

When a project is linked to a GitHub repository, the corresponding decoration (the small GitHub icon close to the project name) is now a link to the GitHub repository.

Some secrets were leaking in the CasC exported configuration (GitHub ingestion token & Slack token). They are now obfuscated. The severity was minor since only administrators could perform such an export.

4.13.16

When defining the configuration for some auto-versioning post-processing based on a GitHub workflow, there are the following changes:

• added the possibility to have a list of arbitrary paramaters that can be passed to the target workflow as inputs
• properties like dockerImage, dockerCommand, commitMessage and the parameters values are all considered as templates. Expressions like ${sourceBuild.release} would be expanded using the auto-versioning templating context. Note that any previous ${...} must be escaped into $${...} if it is not a template

Example:

postProcessing: github
postProcessingConfig:
  dockerImage: some/image
  dockerCommand: './command.sh ${VERSION}'
  commitMessage: 'Upgrading to version ${VERSION}'
  parameters:
    - name: buildName
      value: '${sourceBuild}'

4.13.13

• When setting autoApproval: true on an auto-versioning config, the "auto-merge token" was required so that an approval could be added to the auto-versioning pull request. In some setup, the pull requests don't need approval to be merged or can be added to the "Bypass list" of the GitHub repository or organization. To comply with both situations (approvals needed or not), the "auto-merge" token presence is now used to check if the pull request must be approved automatically or not. No need to change any configuration nor settings.

4.13.8

• Template expressions can be escaped using a double dollar sign ($$). For example, in the This is not an $${expression} template, the result would be evaluated to This is not an ${expression}

4.13.4

• Parameters and commands for the Jenkins auto-versioning post-processing are templates

4.12

The 4.12 introduces changes in how auto-versioning is managed in the backend.

4.12.3

All dependencies of Ontrack have been upgraded to their latest compatible & secure minor version.

If deploying with the Helm chart, using the Ontrack Helm chart 0.13.1 or later is recommended.

4.12.0

The following configuration properties are not used any longer:

• ONTRACK_EXTENSION_AUTO_VERSIONING_QUEUE_PROJECTS - it is no longer possible to create specific queues for the auto-versioning of some projects and it should not be needed any longer
• ONTRACK_EXTENSION_AUTO_VERSIONING_QUEUE_ASYNC - auto-versioning management is always asynchronous

4.11

The 4.11 release introduces a couple of major changes, some visible, some in the background.

4.11.0

License and feature model

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.

Preview of environments and deployments

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.

Workflow engine performance optimizations

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.

Promotions in the build page [Next UI]

The promotions in the build page are now displayed horizontally instead of vertically. This allows for a better support for extra features like deployments.

API changes

• the GraphQL WorkflowInstance.context field has been replaced by WorkflowInstance.event
• the type of the id field for all project entities has been changed from Int! to ID! - the only impact is that these fields are now returned in the JSON as strings instead of numbers ("12" instead of 12)

Misc

• different warnings in the Next UI were persistent. You can now dismiss them.

4.10

4.10.3

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.

4.10.2

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.

4.10.0

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/rpmVersion

In this case, we want the auto-versioning to:

• update the one-version property of the gradle.properties file using the version of the build having been promoted
• update the global.oneVersion property of the manifest.toml file, but this time using the rpmVersion meta-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.

4.9

4.9.9

Automated deletion of branches for auto-versioning

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.

Version source links

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/dependency to get the version of a build linked to the promoted build for the dependency project
• link/dependency/my-qualifier using 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.

4.9.7

Notifications linked to a promotion can now be seen in the promotion run page:

4.9.6

Tracking of auto-versioning

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.

Tracking in the promotion run page

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).

Tracking in the promotion level page

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.

Accessing the promotion runs

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

Tracking in the audit details

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.

4.9.5

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).

4.9.4

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:

4.9.0

Subscription names

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.