Processes and Reference for CI/CD

Version Sourcing

• For obtaining version information of the component in question, the CI relies on the commit hashes and tags of the VCS.
• For obtaining version information of the dependencies of the component in question, the CI relies on a “DEPENDENCIES” file in the root of the code repository.
• Maintainers may represent the version of their component as part of the source code via a VERSION file. But the CI should be agnostic to that.

DEPENDENCIES file

1st party dependencies for each project should be defined in a file named DEPENDENCIES in the root of the project’s repository.

The file should use a simple key=value format, where the key is the dependencies name, and the value is the version string.

Git tags are preferred over SHA hashes to reference versions when possible.

Example

Example DEPENDENCIES file for pEpJNIAdapter.

libpEpAdapter=Release_2.1.4
pEpEngine=Release_2.1.13
sequoia=365d00a08bec6a5a48d48a7c7893d78c27092b59

VERSION file

The project/component version MAY be specified in a VERSION file in the root of the project’s repository.

This file SHOULD only contain the semver of the project and nothing more.

Example

Example VERSION file:

2.1.4

CI Pipelines

There will be 4 different variations of pipelines:

• Per Commit
• Test Version (Tagged)
• Release Candidate (Tagged)
• Release (Tagged)

Test Version Pipelines

This type of pipeline is triggered when a new tag is pushed, on any branch, which meets the following naming criterea:

TEST-<JIRA-ticket>

eg. TEST-ENGINE-814

This pipeline will override the component versions in the DEPENDENCIES file with the newset TEST-<JIRA-ticket>-* tag for each component.