Skip to content

Latest commit

 

History

History
72 lines (59 loc) · 3.32 KB

build-and-release-101.md

File metadata and controls

72 lines (59 loc) · 3.32 KB

Build

The alfresco-extension-inspector project uses GitHub Actions.
The ci.yml config file can be found in the .github/workflows directory of the project.

Stages and Jobs

  1. tests: Java Build with Unit Tests, Veracode scan
  2. release: Publish to Nexus
  3. publish: Copy to S3

Branches

GitHub Actions CI builds differ by branch:

  • master / support/* branches:
    • regular builds which include the tests stage;
    • if the commit message contains the [release] tag, the builds will also include the release stage;
    • if the commit message contains the [publish] tag, the builds will also include the publish stage;
    • PR builds where the latest commit contains the [release] tag will execute dry runs of the release jobs (no artifacts will be published until the PR is actually merged).
  • feature/* branches:
    • regular builds which include the Unit Tests and Source Clear Scan (SCA) jobs;

All other branches get ignored by default.

Release process steps & info

Prerequisites:

  • the master / support/* branch is green and it contains all the changes that should be included in the next release.

Steps:

  1. Create a new branch with the (recommended, but not necessary) name feature/ACS-###_release_version from the master / support/* branch.

  2. Update the project version if the current POM version is not the next desired release; use a maven command, i.e.

    mvn versions:set -DnewVersion=#.##.#-SNAPSHOT versions:commit

  3. Update the project's dependencies (remove the -SNAPSHOT suffixes - only for dependencies, not for the local project version).

  4. Create a new commit with the [release] tag in its message. If no local changes have been generated by steps (2) and (3), then an empty commit should be created - e.g.

    git commit --allow-empty -m "ACS-###: Release #.##.# [release]"

    The location of the [release] tag in the commit message is irrelevant.

    If for any reason your PR contains multiple commits, the commit with the [release] tag should be the last (newest) one. This will trigger the Release dry runs. When merging the PR, it's safest to use the "Squash and merge" option, and during the squash dialog you should ensure that the [release] string is included in the commit message.

  5. Open a new Pull Request from your feature/ACS-###_release_version branch into the original master / support/* branch and wait for a green build; the release stage on the PR build will only execute a Dry_Run of the release.

  6. Once it is approved, merge the PR, preferably through the Rebase and merge option. If the Create a merge commit (Merge pull request) or Squash and merge options are used, you need to ensure that the commit message contains the [release] tag (sub-string).

Company Release process steps & info

Prerequisites:

  • The release stage is complete - i.e. the release commit is tagged and the release artifacts are deployed on Nexus.

Steps:

  1. Checkout the branch used for the Maven Release (the branch that contains the release tag).

This job uses the latest git tag on the current branch to identify the version is to be copied into the S3 release bucket.

  1. Create an empty commit with the [publish] tag in its message.
  2. Push your local commit to origin