ci: automate openapi artifact regeneration on release PRs

[gildesmarais]

This pull request updates the release and CI automation to better manage versioning and OpenAPI artifact generation, especially during release PRs. The changes ensure that frontend and OpenAPI artifacts are kept in sync with backend releases and automates regeneration and committing of these artifacts when needed.

Release automation enhancements:

• .github/release-please-config.json: Configured release-please to update additional files on release, including frontend/package.json (version), public/openapi.yaml, and generated frontend API client files, ensuring all relevant artifacts are versioned together.

CI workflow improvements:

• .github/workflows/ci.yml: Updated the actions/checkout step to use a custom token if available, improving permissions for CI/CD workflows.
• .github/workflows/ci.yml: Enhanced the OpenAPI verification step to allow release PRs to proceed even if OpenAPI artifacts are out of date, and added a new step that automatically regenerates and commits OpenAPI spec and client files during release PRs when needed. This reduces manual intervention and ensures that generated artifacts are always up to date in release branches.

[Copilot]

Pull request overview

This PR aims to keep generated OpenAPI artifacts (spec + frontend client) in sync automatically during release-please version bump PRs by letting CI regenerate and commit when verification fails.

Changes:

• Update CI OpenAPI job checkout to use a write-capable token and add a “regenerate + commit + push” path for release-please PRs.
• Update release-please config to bump versions in additional files (frontend package.json + OpenAPI / generated client artifacts).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

File	Description
.github/workflows/ci.yml	Attempts to auto-regenerate and push OpenAPI artifacts when verification fails on release-please PRs.
.github/release-please-config.json	Adds extra-files so release-please updates frontend/package.json and additional artifacts.

[Copilot]

On pull_request events, actions/checkout defaults to checking out a detached merge commit (refs/pull/*/merge). The later git commit/git push step will fail from a detached HEAD ("not currently on a branch") or push to an unexpected ref. Check out the PR head branch explicitly (e.g., set ref to the PR head ref/sha, and consider fetch-depth: 0) so commits can be pushed back to the release-please branch.

Suggested change

	token: ${{ secrets.RELEASE_PLEASE_TOKEN || github.token }}
	token: ${{ secrets.RELEASE_PLEASE_TOKEN || github.token }}
	ref: ${{ github.head_ref || github.ref_name }}
	fetch-depth: 0

[Copilot]

The regeneration path is gated only by the branch name prefix. A forked PR could use the same release-please--* branch name; in that case the workflow would attempt to commit/push back to a repository it doesn't have access to, causing CI failures. Mirror the safety guard used in .github/workflows/release_artifacts.yml by additionally checking the PR head repo matches github.repository (and/or event type is pull_request).

Suggested change

	if: steps.verify.outcome == 'failure' && startsWith(github.head_ref, 'release-please--')
	if: steps.verify.outcome == 'failure' && github.event_name == 'pull_request' && startsWith(github.head_ref, 'release-please--') && github.event.pull_request.head.repo.full_name == github.repository

[Copilot]

This job performs git push but the workflow/job doesn't request contents: write permissions. If the repository default GITHUB_TOKEN permission is read-only, the push will fail and the automation won't work. Add an explicit permissions: contents: write for the openapi job (or workflow) when using github.token as a fallback.

[Copilot]

git commit will fail the step if there are no staged changes (e.g., if openapi-verify failed for a reason other than generated file drift). Add a guard (like a git diff --quiet check) before committing/pushing so the workflow doesn't error out unnecessarily.

Suggested change

	git commit -m "chore: regenerate openapi spec and client for version bump"
	git push
	echo "## OpenAPI artifacts regenerated" >> "$GITHUB_STEP_SUMMARY"
	echo "Version bump detected; OpenAPI spec and frontend client have been regenerated and committed." >> "$GITHUB_STEP_SUMMARY"
	if ! git diff --cached --quiet; then
	git commit -m "chore: regenerate openapi spec and client for version bump"
	git push
	echo "## OpenAPI artifacts regenerated" >> "$GITHUB_STEP_SUMMARY"
	echo "Version bump detected; OpenAPI spec and frontend client have been regenerated and committed." >> "$GITHUB_STEP_SUMMARY"
	else
	echo "## OpenAPI artifacts unchanged" >> "$GITHUB_STEP_SUMMARY"
	echo "OpenAPI verification failed, but regenerating the tracked OpenAPI spec and frontend client produced no staged changes." >> "$GITHUB_STEP_SUMMARY"
	fi

[Copilot]

This regeneration+push behavior largely overlaps with the existing .github/workflows/release_artifacts.yml automation that refreshes OpenAPI artifacts for release-please branches. Keeping both paths increases the chance of redundant commits and harder-to-debug CI behavior; consider consolidating to a single workflow/trigger (or ensuring they can't both act on the same branch).

[Copilot]

extra-files is intended for release-please to update version strings, but the listed generated TS files currently don't contain the app version (e.g., 1.0.0 does not appear in client.gen.ts). This makes these entries ineffective at best and can be confusing to maintain; consider removing the TS files here (or adding a version marker/updater that actually matches something in those files).

Suggested change

	"public/openapi.yaml",
	"frontend/src/api/generated/client.gen.ts",
	"frontend/src/api/generated/sdk.gen.ts",
	"frontend/src/api/generated/types.gen.ts",
	"frontend/src/api/generated/index.ts"
	"public/openapi.yaml"