Provide Build to QA

Select Project

QA Build History (last 10 days)
Date / Time User Project Branch Status Tag SHA Error Run
Expand to load history…

Finalize Sprint

Sprint Information

Select Projects

Select the projects to include in this sprint release, or copy the setup from a previous release (projects, dependencies and email — versions stay auto-filled from each project's version file).

Loading projects...

Release History

Expand to load history…

Release New Build

Select Services

Choose every service in this release, then set its release branch on the service's own row.

Loading services…

Release Build History (last 10 days)
Date / Time User Project Branch Status Tag SHA Error Run
Expand to load history…

Version Control

What shipped in each release: versions, Jira items and component compatibility, as recorded when the release was finalized.

Cleanup

Settings

Projects

Name Group Git Repository Harbor Project Default Branch Has Develop Actions
Loading...

Regenerate Changelogs

Re-runs changelog generation for a past release and commits the pages to the default branch, the dev branch and the release branch. The commit range is pinned to what the release shipped, so this changes how the pages are written, not which commits they list. Files that come out identical are not committed.

Select a release to list its projects.

Committing the pages does not publish them — the portal is a built site. Leave this on unless you are regenerating several releases in a row and would rather build once at the end.

Resend Release Email

Sends the announcement of a past release again — use it when the first email went out wrong (bad changelog links, a missing recipient). The email is rebuilt from the release record, so it carries the current, corrected links. Preview it before sending: this goes to real inboxes.

Resend Version Control Email

Announces a published manifest again — publication announces once and cannot be repeated (a published manifest is history). Use it when the first email went out with no recipients, while SMTP was down, or before the docs portal had finished building and the link still 404'd. Preview it first: this goes to real inboxes.

Email Templates

Paste the email's HTML. Leave empty to use the built-in styled email. Use Preview to see it rendered.
QA variables: {{project_name}}, {{build_number}}, {{branch}}, {{repository}}, {{image_url}}, {{image_tag}}, {{image_tags}}, {{image_digest}}, {{release_notes}}, {{dependencies}}, {{provenance}}, {{jenkins_create_env_url}}

Default Recipients

Who is told a manifest is published — the people who deploy it. Empty falls back to Release Recipients.
Always told when a QA build is submitted from a Jira issue, alongside whoever pressed Submit. Only @friendly-tech.com addresses are accepted.

QA Builds from Jira

How long a built-but-unsubmitted build keeps its branch before the group is abandoned and the branch released. Default 8.
How many times one failed service may be retried inside a build. 0 turns retrying off. Default 2.
The ceiling across the whole installation. Every live build costs the server a GitHub poll every few seconds. Default 10.

Admin Access

Comma-separated list. Users matching these emails get admin privileges.

SMTP Settings

Integrations

The site the Jira app may call from. A token from any other site is refused.
Pinned so one site's install cannot act as another's. It changes when the app is reinstalled — update it here after forge install --upgrade, or every build is refused.
Resolved by name automatically; set it here only to override. It narrows which services an issue could be built for.
On (the default) anyone who can see the issue and comment on it may build it. Off, only the account IDs below may.
Used only when the box above is off. Empty with the box off means nobody can build, which is deliberate — fill it before turning the box off.