alfresco-transform-core/docs/build-and-release.md

Build

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

Stages and Jobs

1. Build: Java build with unit and integration tests.
2. Release: Release with artifact deployment to Nexus, DockerHub and Quay.io.

Branches

GitHub Actions CI builds differ by branch:

• master / SP/* / HF/* branches:
  • regular builds which include the Build stage;

    On the master branch only the Build stage updates the latest T-Engines images on both Quay and DockerHub:

    • alfresco/alfresco-pdf-renderer
    • alfresco/alfresco-imagemagick
    • alfresco/alfresco-tika
    • alfresco/alfresco-libreoffice
    • alfresco/alfresco-transform-misc
    • alfresco/alfresco-transform-core-aio

  • if the commit message contains the [release] tag, the builds will also include the Release stage;
• ATS-* / ACS-* branches:
  • regular builds which include only the Build and Tests stages;

All other branches are ignored.

Release process steps & info

Prerequisites:

• the master / SP/* / HF/* 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 name ATS-###_release_version from the master / SP/*/ HF/* 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 "ATS-###: Release T-Core (T-Engines) #.##.# [release]"
   

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

5. Open a new Pull Request from the ATS-###_release_version branch into the original master / SP/* / HF/* branch and wait for a green build.

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