diff --git a/.travis.yml b/.travis.yml index c942d1c8..86f29f4e 100644 --- a/.travis.yml +++ b/.travis.yml @@ -19,8 +19,7 @@ branches: only: - master - /^SP\/.+$/ - - release - - /^release\/SP\/.+$/ + - /^HF\/.+$/ - company_release - /^ATS-.*$/ @@ -31,7 +30,7 @@ stages: jobs: include: - - name: "Build" + - name: "Build + Tests" stage: build if: branch NOT IN (company_release) before_install: bash _ci/init.sh @@ -46,7 +45,7 @@ jobs: - name: "Release" stage: release - if: branch = release OR branch =~ /^release\/SP\/.+$/ + if: commit_message ~= /\[trigger release\]/ AND branch ~= /^(master|SP\/.+|HF\/.+)$/ before_install: bash _ci/init.sh before_script: travis_wait bash _ci/cache_artifacts.sh script: travis_wait 30 bash _ci/release.sh diff --git a/docs/build-and-release.md b/docs/build-and-release.md index 0c1d88bb..b9466530 100644 --- a/docs/build-and-release.md +++ b/docs/build-and-release.md @@ -4,36 +4,29 @@ The `.travis.yml` config file can be found in the root of the repository. ## Stages and Jobs -1. **Build**: Java Build with Unit and Integration Tests, WhiteSource -2. **Release**: Publish to Quay & DockerHub, Publish the S3 staging -3. **Company Release**: Publish to S3 release +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`: - - regular builds which include only the _Build_ stage; - - the _Build_ stage updates the `latest` T-Engines images (only - from the `master` branch) on both Quay and DockerHub: - - alfresco/alfresco-pdf-renderer - - alfresco/alfresco-imagemagick - - alfresco/alfresco-tika - - alfresco/alfresco-libreoffice - -* `ATS-*` (any branch starting with "ATS-"), `SP/1.3.N` and `SP/2.0.N`: - - regular builds which include only the _Build_ stage; - - although built and used on the CI agent, no docker images are updated on remote repositories; -* `release`: - - builds that include the _Build_ and _Release_ stages; - - PR builds with release as the target branch only execute dry runs of the actual release, - without actually publishing anything; -* `release/SP/1.3.N` and `release/SP/2.0.N`: - - builds that include the _Build_ and _Release_ stages; - - PR builds with one of the release branches as the target branch only execute dry runs of the actual release, -without actually publishing anything; - - the branches should be deleted once the builds are completed -* `company_release`: - - builds that include only the `company_release` stage; +* `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 + - 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. @@ -42,65 +35,43 @@ All other branches are ignored. ## Release process steps & info Prerequisites: - - the `master` branch has a green build and it contains all the changes that should be included in - the next release + - 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 from the `master` branch with the name `ATS-###_release_version`; -2. (Optional) 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=2.0.19-SNAPSHOT versions:commit`; -3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes) through a new commit on the - `ATS-###_release_version` branch; -4. Open a new Pull Request from the `ATS-###_release_version` branch into the `release` branch and - wait for a green build; the **Release** stage on the PR build will only execute a _Dry_Run_ of - the release; -5. Once it is approved, merge the PR through the **Create a merge commit** option (as opposed to - _Squash and merge_ or _Rebase and merge_), delete the `ATS-###_release_version` branch, and wait - for a green build on the `release` branch; -6. Merge back the `release` branch into the `master` branch; -7. Update the project dependencies (append the `-SNAPSHOT` suffixes) +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. + ```bash + 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. + ```bash + git commit --allow-empty -m "ATS-###: Release AIS #.##.# [trigger release]" + ``` + + > The location of the `[trigger release]` tag in the commit message is irrelevant. -Steps (6) and (7) can be done either directly from an IDE or through the GitHub flow, by creating -another branch and PR. Just make sure you don't add extra commits directly to the release branch, -as this will trigger another release. - -After the release, the reference deployments (docker-compose, helm) should be updated with the -latest docker image tags. - -### Release of a Service Pack (SP/1.3.N or SP/2.0.N) -Prerequisites: - - the `SP/` ( could be 1.3.N or 2.0.N) branch has a green build and it contains all the changes that should be included in - the next release - -**NOTE**: Make sure you release the proper version and the `SP/` is merged into the correct `release/SP/` (both having the same version). -E.g. When releasing a 1.3.N Service Pack, a new branch (`ATS-###_release_version`) should be created from `SP/1.3.N` and the PR should target the `release/SP/1.3.N` branch. - -Steps (similar to those describing the release from `master`): -1. Create a new branch from the `SP/` (SP/1.3.N or SP/2.0.N) branch with the name `ATS-###_release_version`; -2. (Optional) 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=1.3.1-SNAPSHOT versions:commit`; -3. Update the project's dependencies (remove the `-SNAPSHOT` suffixes) through a new commit on the - `ATS-###_release_version` branch; -4. Open a new Pull Request from the `ATS-###_release_version` branch into the `release/SP/` branch and - wait for a green build; the **Release** stage on the PR build will only execute a _Dry_Run_ of - the release; -5. Once it is approved, merge the PR through the **Create a merge commit** option (as opposed to - _Squash and merge_ or _Rebase and merge_), delete the `ATS-###_release_version` branch, and wait - for a green build on the `release` branch; -6. Merge back the `release/SP/` branch into the `SP/` branch; -7. Update the project dependencies (append the `-SNAPSHOT` suffixes) + > 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: - - Engineering Release of the desired version has been done. - -Steps: -1. Create a new `company_release` branch from `release`. This job uses the git tag to identify the - version to be uploaded to S3 release bucket. -2. If the last commit on `company_release` branch contains `[skip_ci]` in its message it will - prevent Travis from starting a build. Push an empty commit in order to trigger the build, - `git commit --allow-empty -m "Company Release "`. Wait for a green build on the branch. -3. Delete local and remote `company_release` branch. + - The **Release** stage is complete - i.e. the release commit is tagged and the release + artifacts are deployed on Nexus. -### Release of a Service Pack (SP/1.3.N or SP/2.0.N) -Follow the steps described in the previous section, but instead of creating the `company_release` from `release`, it needs to be created from the proper `release/SP/` (depending on what version needs the Company Release). +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.