A repository to collect all the initiatives around Observability currently being worked on at Canonical.
A list of all the active repositories maintained by the Observability team can be found using the observability topic.
Want to know more? See the CharmHub topic page on Observability.
This repository holds all of our reusable workflows, in the .github/workflows
folder; our other repositories implement their workflows by calling these. We follow two conventions for naming them:
- workflows starting with
_
are “private”, meaning they are used by other workflows and shouldn't be called directly; - the name should loosely follow a
{scope}-{function}.yaml
schema, to make the folder easily searchable.
Issues are synced by the gh-jira-sync-bot, and further enriched by a Jira Automation.
The bot configuration lives in .github/.jira_sync_config.yaml; carefully read the README to configure it. This takes care of most things, except the Jira labels, which are added by the Jira automation.
On PRs | On main | Periodically | Manually |
---|---|---|---|
charm-pull-request.yaml |
charm-release.yaml |
charm-update-libs.yaml |
charm-promote.yaml |
└── _charm-quality-checks.yaml |
├── _charm-quality-checks.yaml |
(charm-update-libs.yaml) |
|
....├── _charm-codeql-analysis.yaml |
....├── _charm-codeql-analysis.yaml |
||
....├── _charm-static-analysis.yaml |
....├── _charm-static-analysis.yaml |
||
....├── _charm-linting.yaml |
....├── _charm-linting.yaml |
||
....├── _charm-tests-unit.yaml |
....├── _charm-tests-unit.yaml |
||
....├── _charm-tests-scenario.yaml |
....├── _charm-tests-scenario.yaml |
||
....└── _charm-tests-integration.yaml |
....└── _charm-tests-integration.yaml |
||
└── _charm-release.yaml |
Whenever a PR is opened to a charm repository, some quality checks are run:
- first check that the
CHARMHUB_TOKEN
secret is set on the repo, as it's needed by other actions; - run the Canonical inclusive naming workflow;
- make sure charm libraries are updated and tag the PR accordingly with "Libraries: OK" or "Libraries: Out of Sync";
- run linting, analyses and tests to ensure the code quality.
After a PR is merged, the same quality checks are run on the main branch; when passing, the CI takes care of publishing any bumped charm library and releasing the charm to edge.
Periodically, CI checks whether the charm libraries are up-to-date; if not (i.e., another charm published an updated library), a PR is automatically opened to update them with the new version.
There's also a manual action to promote the charm (i.e., from latest/edge
to latest/beta
), making the process more user-friendly.
On PRs |
---|
bundle-pull-request.yaml |
├── _charm-codeql-analysis.yaml |
├── _charm-linting.yaml |
└── _charm-tests-integration.yaml |
Whenever a PR is opened to a bundle repository, some quality checks are run:
- first check that the
CHARMHUB_TOKEN
secret is set on the repo, as it's needed by other actions; - run the Canonical inclusive naming workflow.
- run linting, analyses and tests to ensure the code quality.
On PRs | On main | Periodically | Manually |
---|---|---|---|
_rock-pull-request.yaml |
rock-release-dev.yaml |
rock-update.yaml |
(rock-release-dev.yaml) |
└── _rock-build-test.yaml |
rock-release-oci-factory.yaml |
(rock-update.yaml) |
Our rocks are built in oci-factory, which covers:
- building and publishing the rocks to DockerHub;
- tagging with semantic versions (e.g.,
prometheus:{major}
pointing to the latestprometheus:{major}.{minor}.{patch}
) - periodically rebuilding rocks to pull any security fix.
These workflows make the repositories holding our rocks almost fully automated: whenever the upstream project releases a new version, a PR is opened automatically to add a rock for that specific version. Consequently, a workflow is run to make a quality check by trying to build the rock locally.
When the PR is merged, the rock is published to the GitHub Container Registry (GHCR) with a :dev
tag. At the same time, a PR is opened to the oci-factory repo for the ROCKS Team to approve and merge, triggering the actual build process.
Manually |
---|
_local-promote-train.yaml |
The Promote Train workflow allows to promote all the charms revisions to their next risk track. Specifically, if the tracks are open, the following promotions will be executed:
latest/candidate
-->latest/stable
latest/beta
-->latest/candidate
latest/edge
-->latest/beta
If the dry-run flag is selected, the promotion will simply be printed instead of being carried out.
This repo also contains the manifest (manifest.yaml
) for syncing all repositories maintained by the observability team.
The script assumes that you want to place all repos in the parent folder of the observability
repo. To use it, do the following:
# install the git-metarepo module
$ pip3 install metarepo
# sync the repos using the manifest
$ git meta sync
This repo also contains a scripts
directory that could hold helper scripts for COS charms and bundles as pip-installables
.
This helper script is used by COS bundles as a pip
package in a tox.ini
file to render a bundle.yaml.j2
template into a bundle.yaml
file that can be deployed using juju deploy ./bundle.yaml
.
To add similar helper scripts (e.g: my_helper.py
) to be used as a pip
package:
- Add the script inside
scripts
directory. - In
scripts/pyproject.toml
, under[project.scripts]
, add an entrypoint to your newly added script.