ci(release): align CT-CVE release workflow branch #9

New issue

Closed

opened 2026-04-30 14:40:11 +00:00 by simonjcarr · 2 comments

simonjcarr commented

2026-04-30 14:40:11 +00:00

(Migrated from github.com)

Problem

CT-CVE releases and GHCR image publishing are not running.

Evidence checked on 2026-04-30:

Repository default branch is feat/bootstrap-service, not main.
.github/workflows/release-please.yml exists on feat/bootstrap-service and is listed as the Release workflow.
The release workflow is configured with on.push.branches: [main].
main is still at PR #1 (d654444) and does not contain the release workflow, release-please config, or later CT-CVE changes.
gh api repos/carrtech-dev/ct-cve/actions/workflows/268881990/runs reports total_count: 0.
gh release list --repo carrtech-dev/ct-cve returns no releases.
The GHCR package lookup for carrtech-dev/ct-cve returns 404/package not found.

Likely fix

Choose the intended release branch and make the workflow match it:

Preferably promote/merge feat/bootstrap-service into main and set main as the default branch, or
Change the release workflow trigger to the actual default/release branch.

After the workflow runs, release-please should create a release PR first. GHCR images will only publish after that release PR is merged and release_created is true.

## Problem CT-CVE releases and GHCR image publishing are not running. Evidence checked on 2026-04-30: - Repository default branch is `feat/bootstrap-service`, not `main`. - `.github/workflows/release-please.yml` exists on `feat/bootstrap-service` and is listed as the `Release` workflow. - The release workflow is configured with `on.push.branches: [main]`. - `main` is still at PR #1 (`d654444`) and does not contain the release workflow, release-please config, or later CT-CVE changes. - `gh api repos/carrtech-dev/ct-cve/actions/workflows/268881990/runs` reports `total_count: 0`. - `gh release list --repo carrtech-dev/ct-cve` returns no releases. - The GHCR package lookup for `carrtech-dev/ct-cve` returns 404/package not found. ## Likely fix Choose the intended release branch and make the workflow match it: 1. Preferably promote/merge `feat/bootstrap-service` into `main` and set `main` as the default branch, or 2. Change the release workflow trigger to the actual default/release branch. After the workflow runs, release-please should create a release PR first. GHCR images will only publish after that release PR is merged and `release_created` is true.

simonjcarr commented

2026-04-30 14:55:51 +00:00

(Migrated from github.com)

Updated 2026-04-30: main has been fast-forwarded past PRs #2-#8 and now contains the CT-CVE work plus release workflow fixes. Release PR #11 was generated against main and merged, creating release ct-cve-v0.2.0. The release workflow pushed GHCR tags ghcr.io/carrtech-dev/ct-cve:ct-cve-v0.2.0 and ghcr.io/carrtech-dev/ct-cve:latest with digest sha256:acace5f398c63277d91605a158004ce444fb9a578a3d4c890bbb05ec606a9870. Follow-up still requiring an admin-scoped token/UI action: change the repository default branch from feat/bootstrap-service to main.

simonjcarr commented

2026-05-04 11:02:52 +00:00

(Migrated from github.com)

Verified on 2026-05-04 that the original release-branch problem is no longer present:

GitHub now reports main as the default branch for carrtech-dev/ct-cve.
.github/workflows/release-please.yml is on main and targets main.
The release workflow has multiple successful runs on main, including the release push on 2026-05-01.
Releases ct-cve-v0.2.0 and ct-cve-v0.3.0 exist.

Given the repo state today, this issue appears resolved and stale rather than an active defect, so I'm closing it as completed.

Verified on 2026-05-04 that the original release-branch problem is no longer present: - GitHub now reports `main` as the default branch for `carrtech-dev/ct-cve`. - `.github/workflows/release-please.yml` is on `main` and targets `main`. - The release workflow has multiple successful runs on `main`, including the release push on 2026-05-01. - Releases `ct-cve-v0.2.0` and `ct-cve-v0.3.0` exist. Given the repo state today, this issue appears resolved and stale rather than an active defect, so I'm closing it as completed.