alfresco-helm-charts

User docs available at: https://alfresco.github.io/alfresco-helm-charts/

Development

Each individual chart is available in the chart directory in charts/.

This repository follows the helm/charts-repo-actions-demo template, that support the testing and the release of helm charts with the help of two tools:

In order to install all the tools required for development on MacOS via Homebrew, run: brew bundle install

To setup pre-commit, run:

pre-commit install

To install required helm plugins:

helm plugin install https://github.com/jtyr/kubeconform-helm --version v0.1.12
helm plugin install https://github.com/helm-unittest/helm-unittest --version v0.3.4

PR workflow

Each time a PR is raised, ct automatically detects which charts has been changed and run for them:

linter
unittest
integration tests on KinD

Once a PR that contains a chart version bump is merged, the main workflow will release each version that has not yet released. Each chart release will trigger the creation of git tag, a GitHub release with packages attached and the update of the charts registry index.

Update dependencies

There is an initial support for bumping charts dependencies with Updatecli via a manually triggered GHA workflow.

Testing

Unit tests and linting

make test alfresco-repository
make lint alfresco-repository

Local integration testing

Some charts need external services (database, message broker, search engine) to run integration tests. These dependencies are declared in test-deps.yaml and managed by scripts/ci-deps.sh.

# Deploy deps, install the chart, then clean up when done:
make install alfresco-repository
make uninstall alfresco-repository

You can also manage dependencies separately:

make setup alfresco-repository      # deploy deps only
make teardown alfresco-repository   # remove deps only

Set a custom namespace with NAMESPACE=alfresco.

CI

Each chart is tested against a default configuration on KinD. You can check the currently tested K8s version by looking at the KINDNODEIMAGE value in the main lint-test workflow.

We are ensuring backward compatibility with older K8s versions with kubeconform. You can check the oldest K8s version tested by looking at kubernetes-version inside the kubeconform-helm-min hook in pre-commit configuration.

Release

Helm charts versioning should follow the principles of semantic versioning. For assistance with version bumping, see the Copilot Instructions which provide guidance when making chart changes.

Agentic release workflow

The recommended path is to trigger the Release Orchestrator agentic workflow from the Actions tab. It automates the bulk of the checklist below — creating prerequisite GA PRs for alfresco-common, activemq, postgres, and elastic, inferring per-chart semver bumps from the updatecli-bump-acs/updatecli-bump-helm diff, and opening a draft release PR. The workflow takes a release codename and an optional Jira ID, uses a GitHub issue as a resumable state machine, and is meant to be re-run as each prerequisite PR is merged. The checklist below remains authoritative for the manual steps it cannot perform — reviewing updatecli bumps, refreshing the supported matrix and docs.hyland.com links in values.yaml, updating UPGRADES.md, and the post-merge acs-deployment update.

Manual release checklist

Ensure alfresco-common version is not a

pre-release, otherwise release it.

Ensure test dependency charts

(postgres, elastic, activemq) are not pre-release versions, otherwise release them first. These are not Helm chart dependencies but are required by CI integration tests (see test-deps.yaml). After releasing them, run the Bump versions workflow with the charts option to update test-deps.yaml automatically.

Ensure

supported-matrix has been manually updated for the latest acs version released and the compatibility matrix is up to date.

For minor releases, ensure to update the links beginning with

https://docs.hyland.com/r/Alfresco to reflect the latest version or corresponding minor update documentation.

Trigger the BumpVersions workflow by executing Bump

version with values option. Optionally you can create a dedicated branch (ticket reference) if you want the workflow changes to be reviewed inside a PR.