mirror of
https://github.com/Alfresco/alfresco-transform-core.git
synced 2025-05-12 17:04:48 +00:00
c28b65fba5
* ACS-2499 Delete company release build stage. This never uploaded any software, and so was not particularly useful. The software and license report should be uploaded to S3 as part of the transform-service build. Also skip uploading anything to staging bucket.
65 lines
2.9 KiB
Markdown
65 lines
2.9 KiB
Markdown
# 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 and integration tests.
|
|
2. **Release**: Release with artifact deployment to Nexus, DockerHub and Quay.io.
|
|
|
|
|
|
## 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;
|
|
|
|
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.
|
|
```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 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).
|
|
|