This project contains the code for running Alfresco Content Services (ACS) with Docker using Docker Compose or on Kubernetes using Helm Charts.
User docs available at: https://alfresco.github.io/acs-deployment/
The code in this repository is released under the Apache License, see the LICENSE file for details.
Please use this guide to make a contribution to the project and information to report any issues.
New releases are usually made from the default branch. When a bugfix release is
necessary and master branch already received updates that are meant to be
released at a later time, then the release must be made from a branch which
follows the release branch pattern: release/v$Major.Minor
.
First ensure that:
- the supported-matrix reflects the status of the currently released Alfresco products and update if necessary before proceeding.
- the components charts have been released in stable versions (no pre-release version should be present in Chart.yaml).
Start the release by opening a PR against the appropriate branch that will:
- Update the EOL table in case a version is deprecated
- In alfresco-content-services, bump chart version to the version you want to release
- Run
pre-commit run --all-files helm-docs
to update helm docs - Edit upgrades docs renaming the
To be released
section to the current version and create a newTo be released
section for the future. - Run Bump versions workflow against the same newly created branch, the
first time with
charts
option. Inspect the changes pushed on the branch, revert unwanted changes if necessary. - Run Bump versions workflow against the same branch with option
values
. This will update both docker compose tags and helm charts values. Inspect the changes pushed on the branch, looking for any missing update.
Once the PR has been merged, create the release with:
git tag -s vx.x.x -m vx.x.x
git push origin vx.x.x
gh release create vx.x.x --generate-notes -t vx.x.x -d
where vx.x.x
is the same alfresco-content-services
Chart version.
Once the workflow triggered by this new tag is successful, review the GitHub release notes, usually removing dependabot entries and other not-really useful changelog entries.
Publish the release (remove draft status).
Once the tagged workflow is successful, the release process is completed.