Add release-plan.yaml rollout campaign by hdamker · Pull Request #103 · camaraproject/project-administration

hdamker · 2026-01-09T18:02:24Z

What type of PR is this?

enhancement/feature

What this PR does / why we need it:

Implements the release-plan.yaml rollout campaign - automated infrastructure to add release-plan.yaml metadata files to all ~61 CAMARA API repositories.

Key features:

Automated generation of release-plan.yaml from releases-master.yaml data
Two template variants: repositories with existing releases vs. new repositories
CODEOWNERS integration: automatically populates main_contacts from repository CODEOWNERS
Validation integration: calls validation action (currently stub via hdamker/tooling@release-plan-validation)
Dry-run mode: plan and preview all changes before creating PRs

Templates for review:

YAML templates (generated release-plan.yaml):

release-plan-with-releases.mustache - for repos with releases
release-plan-no-releases.mustache - for new repos

PR body templates (PR descriptions for target repos):

Testing Status

Apply mode test (3 repos): Successful run 21092880099

Created test PRs:

Dry-run test (all repos): Successful run (2 minutes)

45 repositories with releases
14 repositories without releases (WIP/new)
3 of the 64 repositories would be skipped in apply (already have PR from apply test)

Which issue(s) this PR fixes:

Fixes #99

Special notes for reviewers:

Feedback requested on:

YAML template structure and comments
PR body template wording and instructions
Default values (target_release_type: none, dependencies versions)

Workflow:

select job: Builds repo list from releases-master.yaml, filters by category, skips repos with existing release-plan.yaml
run job (matrix): For each repo: fetch CODEOWNERS → generate YAML → validate → create PR
aggregate job: Merges all per-repo results into campaign summary

Changes:

New campaign: campaigns/release-plan-rollout/
New action: generate-release-plan (TypeScript, Mustache templates)
Simplified campaign-finalize-per-repo (removed superseding logic)
Validation step integration (stub, to be replaced with camaraproject/tooling@v0)

Before production rollout:

Change validation action reference from hdamker/tooling@release-plan-validation to camaraproject/tooling@v0 (after shared-action is released)

Changelog input

Add release-plan.yaml rollout campaign for automated metadata file deployment across CAMARA repositories

Additional documentation

See campaigns/release-plan-rollout/docs/README.md for usage documentation

- Refactor campaign-finalize-per-repo for generic reuse - Add INCLUDE filter to release-info workflow - Create release-plan-rollout campaign workflow and actions - Add generate-release-plan TypeScript action - Add PR body template and documentation Fixes camaraproject#99

…ject#99) - Add include_wip_repos and include_new_repos workflow inputs - Update select job to use repositories array with API file detection - Categorize repos: with-release, WIP (has API files), new (no API files) - Generate placeholder release-plan.yaml for repos without releases - Add warning section in PR body template for placeholders - Update aggregation summary with category breakdown - Update campaign documentation

- Add UX-reviewed templates for repos with/without releases - Use Mustache for YAML generation with code-appended API section - Fetch CODEOWNERS and include all in main_contacts - Simplify campaign-finalize-per-repo: skip if PR exists (no superseding)

- Remove duplicate meta_release entry (consolidated conditional block) - Update meta_release comment: "update for next cycle when planning" - Update target_release_type comment in both templates: "must be set before release can be triggered"

- Enable validation via hdamker/tooling@release-plan-validation (stub) - Add log step showing validation result (valid, errors, warnings) - Skip PR creation when validation fails, report error in summary - Remove target_release_type and pr_body_template from summary output

hdamker · 2026-01-09T18:41:06Z

@tanjadegroot @camaraproject/release-management_maintainers the workflow is not yet 100% complete and not fully tested, but I would like to get already your comments on the four templates. They are designed along the following principles:

Safe to merge as-is: Pre-populated from existing release data and CODEOWNERS; target_release_type: none ensures no accidental releases — maintainers verify rather than fill in from scratch
Evergreen comments: No specific version numbers in explanatory comments in the YAML(e.g., "increment first number" not "r3.2 → r4.1") so guidance stays valid after updates
PR description does the heavy lifting: Detailed instructions in the one-time PR description; YAML comments kept minimal since the file will be edited repeatedly
Declare intent, don't trigger: The file expresses what maintainers plan to release; actual release triggering happens externally

Three examples of generated release-plan.yaml files (from https://github.com/hdamker/project-administration/actions/runs/20861601808):

release-plan (qod).yaml (there APIs, meta-release track)
release-plan (ctd).yaml (pre-release only yet, independent track)
release-plan (ConsentManagement).yaml (no release yet)

campaigns/release-plan-rollout/templates/release-plan-no-releases.mustache

campaigns/release-plan-rollout/templates/pr-body-with-releases.mustache

- campaign-finalize-per-repo: derive git user identity from github_token via gh api user (removes hardcoded/configurable git_user_name/email) - Templates: update docs URL to ReleaseManagement/tree/main/documentation - PR body templates: add three documentation links (full docs, workflow spec, API versioning guide)

In apply mode, artifacts are named results-* not plan-*. The aggregate job now detects the mode and uses the correct pattern and file names.

Kevsy · 2026-01-14T12:02:26Z

Thanks @hdamker I've checked and proofread all the templates, looks good 👍

Just a couple of minor comments:

release-plan-no-releases.mustache/ release-plan-with-releases.mustache

For:

 # Uncomment and set when planning a meta-release participation:
  # meta_release: Fall26

...may be worth stating the meta-release syntax (i.e. no space between the classifier and the year: Fall26 ✅ , Falll 26 ❌ )

release-plan-no-releases.mustache/ release-plan-with-releases.mustache

For:

# APIs in this repository
# Update with your actual API(s) when ready:
# - api_name: kebab-case identifier (will be filename in code/API_definitions/)
# - target_api_status: draft (no file yet) | alpha (file exists) | rc | public
apis:

...please can you include a commented example showing the apis: object structure with at least two APIs included? It's not clear to me from the current example how to do that.

hdamker · 2026-01-14T12:08:32Z

...please can you include a commented example showing the apis: object structure with at least two APIs included? It's not clear to me from the current example how to do that.

Hi @Kevsy they are not included in the templates as they will be generated within the workflow based on the existing APIs, see for example in camaraproject/QualityOnDemand#523. For a new repository without prior release there is an example added, see camaraproject/ConsentManagement#7

Regarding "Fall26" vs "Fall 26" ... good point to add this to the validation (allowing currently only Spring26 and Fall26, if we support maintenance releases also Fall25).

Avoids GitHub's "bidirectional Unicode text" warning banner when viewing generated release-plan.yaml files.

- Update API section comments in release-plan-no-releases.mustache - Rename example-api to placeholder-entry for clarity - Update PR body template to match

Removes remaining Unicode characters (U+2014 EM DASH) that triggered GitHub's bidirectional text warning banner.

- Update workflow comment to describe CI validation and release generation - Clarify target_release_tag comment in with-releases template - Add explicit note about target_release_tag pre-fill in PR body

hdamker · 2026-01-18T17:14:19Z

Regarding "Fall26" vs "Fall 26" ... good point to add this to the validation (allowing currently only Spring26 and Fall26, if we support maintenance releases also Fall25).

Pattern validation was already within the script, now also validating against the list of concrete valid values (as of now Fall25 (for maintenance releases), Spring26, Fall26). See camaraproject/tooling@7543d1e within camaraproject/tooling#48

Kevsy

LGTM

- Replace "work in progress" link with Release Management Documentation - Add specific link to release-plan.yaml documentation - Add link to Release Lifecycle (explains workflow phases) - Simplify API Versioning link text

hdamker · 2026-01-20T21:54:16Z

Updated the documentation links in 699e907, they are now dependent on the merge of camaraproject/ReleaseManagement#364 (PR can be merged and tested on repositories earlier, but documentation links will not work)

- Update actions/checkout v4 -> v6 - Update actions/github-script v7 -> v8 - Update actions/setup-node v4 -> v6 - Update actions/upload-artifact v4 -> v6 - Update actions/download-artifact v4 -> v7 - Update actions/upload-pages-artifact v3 -> v4 - SHA pin peter-evans/create-pull-request to v8.0.0 - Add dependabot.yml for automated weekly updates

hdamker · 2026-01-20T22:04:40Z

Done here in this PR branch:

Security hardening: Update GitHub Actions and add Dependabot*

Updates all GitHub Actions to their latest major versions and adds automated dependency management:

Action	Change
checkout	v4 → v6
github-script	v7 → v8
setup-node	v4 → v6
upload-artifact	v4 → v6
download-artifact	v4 → v7
upload-pages-artifact	v3 → v4
peter-evans/create-pull-request	v5 → v8 (SHA pinned)

Third-party action peter-evans/create-pull-request is SHA-pinned for supply chain security.

Added dependabot.yml for weekly automated updates with grouped PRs.

albertoramosmonagas

Just a few questions, but LGTM!

.github/workflows/campaign-release-plan-rollout.yml

campaigns/release-plan-rollout/actions/generate-release-plan/src/index.ts

Kevsy

LGTM

rartych

LGTM

hdamker and others added 10 commits January 7, 2026 22:00

Merge branch 'camaraproject:main' into release-plan-rollout-campaign

5243edf

Include generated files in plan mode artifacts

26b08b7

Fix dry-run: aggregate subdirs, JSON output, new file detection

75fdc19

Fix shell test syntax for JSON array in warnings output

7581a5a

Add commented meta_release hint for independent repos

f03e464

rartych reviewed Jan 12, 2026

View reviewed changes

campaigns/release-plan-rollout/templates/release-plan-no-releases.mustache Outdated Show resolved Hide resolved

rartych reviewed Jan 12, 2026

View reviewed changes

campaigns/release-plan-rollout/templates/pr-body-with-releases.mustache Outdated Show resolved Hide resolved

hdamker and others added 4 commits January 12, 2026 09:54

Merge branch 'camaraproject:main' into release-plan-rollout-campaign

96b35fa

Fix aggregate job to run in both dry-run and apply modes

a5dd94d

Fix aggregate job to use mode-aware artifact pattern and file names

68ee8d1

In apply mode, artifacts are named results-* not plan-*. The aggregate job now detects the mode and uses the correct pattern and file names.

hdamker marked this pull request as ready for review January 13, 2026 21:35

hdamker requested review from a team as code owners January 13, 2026 21:35

hdamker mentioned this pull request Jan 14, 2026

Monitor release-plan.yaml rollout to all repositories camaraproject/ReleaseManagement#357

Closed

16 tasks

hdamker added 4 commits January 17, 2026 10:41

Replace Unicode arrows with ASCII in templates

c0c2d40

Avoids GitHub's "bidirectional Unicode text" warning banner when viewing generated release-plan.yaml files.

Improve no-releases template: rename example-api to placeholder-entry

92c2ae7

- Update API section comments in release-plan-no-releases.mustache - Rename example-api to placeholder-entry for clarity - Update PR body template to match

Replace em-dashes with ASCII double-hyphens in templates

f652112

Removes remaining Unicode characters (U+2014 EM DASH) that triggered GitHub's bidirectional text warning banner.

Improve template comments and PR body clarity

736d72d

- Update workflow comment to describe CI validation and release generation - Clarify target_release_tag comment in with-releases template - Add explicit note about target_release_tag pre-fill in PR body

Kevsy previously approved these changes Jan 19, 2026

View reviewed changes

Update documentation links to new structure

699e907

- Replace "work in progress" link with Release Management Documentation - Add specific link to release-plan.yaml documentation - Add link to Release Lifecycle (explains workflow phases) - Simplify API Versioning link text

hdamker dismissed Kevsy’s stale review via 699e907 January 20, 2026 21:50

hdamker requested review from Kevsy and rartych January 20, 2026 21:54

albertoramosmonagas approved these changes Jan 27, 2026

View reviewed changes

.github/workflows/campaign-release-plan-rollout.yml Show resolved Hide resolved

campaigns/release-plan-rollout/actions/generate-release-plan/src/index.ts Show resolved Hide resolved

campaigns/release-plan-rollout/actions/generate-release-plan/src/index.ts Show resolved Hide resolved

Kevsy approved these changes Jan 27, 2026

View reviewed changes

rartych approved these changes Jan 27, 2026

View reviewed changes

hdamker merged commit e485feb into camaraproject:main Jan 27, 2026
1 check passed

hdamker mentioned this pull request Feb 17, 2026

Fix release-plan rollout campaign for production use #135

Closed

Conversation

hdamker commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What type of PR is this?

What this PR does / why we need it:

Testing Status

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

Additional documentation

Uh oh!

hdamker commented Jan 9, 2026

Uh oh!

Uh oh!

Uh oh!

Kevsy commented Jan 14, 2026

Uh oh!

hdamker commented Jan 14, 2026

Uh oh!

hdamker commented Jan 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kevsy left a comment

Choose a reason for hiding this comment

Uh oh!

hdamker commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hdamker commented Jan 20, 2026

Uh oh!

albertoramosmonagas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kevsy left a comment

Choose a reason for hiding this comment

Uh oh!

rartych left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

hdamker commented Jan 9, 2026 •

edited

Loading

hdamker commented Jan 18, 2026 •

edited

Loading

hdamker commented Jan 20, 2026 •

edited

Loading