mirror of
https://github.com/Alfresco/alfresco-transform-core.git
synced 2025-05-12 17:04:48 +00:00
80 lines
3.6 KiB
Markdown
80 lines
3.6 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 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.
|
|
```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).
|
|
|
|
## 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.
|