Skip to content

Latest commit

 

History

History
79 lines (67 loc) · 3.65 KB

build-and-release.md

File metadata and controls

79 lines (67 loc) · 3.65 KB

Build

The alfresco-transform-core project uses Travis CI.
The .travis.yml config file can be found in the root of the repository.

Stages and Jobs

  1. Build: Java build with unit tests, integration tests and WhiteSource scan.
  2. Release: Release with artifact deployment to Nexus and AWS Staging bucket.
  3. Company Release: Artifact deployment to AWS Release bucket.

Branches

Travis 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 [trigger release] tag, the builds will also include the Release stage;
    • PR builds where the latest commit contains the [trigger release] tag will execute dry runs of the release jobs (no artifacts will be published until the PR is actually merged).
  • ATS-* branches:
    • regular builds which include only the Build and Tests stages;
  • company_release branch:
    • builds that include the Company Release stage only.
    • the company_release branch should be used for one-off events; once used (a build completes), the branch should be deleted.

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 [trigger 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) #.##.# [trigger release]"

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

    If for any reason your PR contains multiple commits, the commit with the [trigger release] tag should be the last (newest) one. This will trigger the Release dry runs.

  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; 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 [trigger 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. Create a new company_release branch from the master / SP/*/ HF/* branch. This job uses the latest branch git tag to identify the version that must be uploaded to the S3 release bucket.
  2. Wait for a green build on the branch.
  3. Delete local and remote company_release branch.