Compare commits
9 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Jon Chery
|
437908662f | ||
|
Jon Chery
|
1c2843a39d | ||
|
Jon Chery
|
82dfe7a941 | ||
|
Jon Chery
|
699196f368 | ||
|
Jon Chery
|
61c97c847c | ||
|
Jon Chery
|
6f04b22df0 | ||
|
Jon Chery
|
eadf2cc2c5 | ||
|
Jon Chery
|
93ac4bda66 | ||
|
Jon Chery
|
454040fdd1 |
+11
-18
@@ -1,24 +1,17 @@
|
||||
{
|
||||
"phase": 8,
|
||||
"stage": "complete",
|
||||
"milestone": "v0.14",
|
||||
"milestone_slug": "ingress-bootstrap",
|
||||
"phase_role": "final",
|
||||
"phase": 0,
|
||||
"stage": "plan",
|
||||
"milestone": "v0.16",
|
||||
"milestone_slug": "release-binary-fix",
|
||||
"phase_role": "pre_execution",
|
||||
"attempts": 0,
|
||||
"updated_at": "2026-08-10T20:30:00Z",
|
||||
"milestone_complete": true,
|
||||
"previous_milestone": "v0.13",
|
||||
"phases_shipped": ["P0","P1","P2","P3","P4","P5","P6","P7","P8"],
|
||||
"tags_shipped": ["v0.13.0","v0.13.1","v0.13.2","v0.13.3","v0.13.4","v0.13.5","v0.13.6","v0.13.7"],
|
||||
"updated_at": "2026-08-12T21:15:00Z",
|
||||
"milestone_complete": false,
|
||||
"previous_milestone": "v0.15",
|
||||
"phases_shipped": [],
|
||||
"tags_shipped": [],
|
||||
"requirements": {
|
||||
"covered": [171,172,173,174,175,176,177,178,179],
|
||||
"covered": [],
|
||||
"partial": []
|
||||
},
|
||||
"binding_conditions": ["C-50","C-51","C-52","C-53","C-54","C-55","C-56","C-57","C-58","C-59","C-60","C-61"],
|
||||
"load_bearing_rule": "R-024",
|
||||
"ship": {
|
||||
"tag": "v0.13.8",
|
||||
"merged_to_milestone": true,
|
||||
"milestone_release": "v0.14"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,51 @@
|
||||
# CLARIFY + RESEARCH + PLAN v0.15: CI Release Pipeline Fix
|
||||
|
||||
## Decisions
|
||||
|
||||
| ID | Decision | Rationale | Confidence |
|
||||
|----|----------|-----------|------------|
|
||||
| D-264 | Secret name = `PAT_TOKEN` (not `GITEA_PAT`) | Gitea reserves `GITEA_` prefix for built-in secrets | 1.0 (validated) |
|
||||
| D-265 | Use `tea actions secrets create` CLI | Operator instruction: no API | 1.0 (validated) |
|
||||
| D-266 | Container publishing in Gitea Actions, not CoreCI | CoreCI's podman executor appends `sh -c` which conflicts with kaniko's `/kaniko/executor` entrypoint. Gitea Actions `container:` supports `options: --entrypoint` | 0.95 |
|
||||
| D-267 | kaniko `executor:debug` image | Includes `/bin/sh`; Gitea Actions can override entrypoint to `/bin/sh` then run kaniko via shell | 0.90 |
|
||||
| D-268 | `coreci run` for validate/build/test/release (tarball); Gitea Actions for container publishing | Clean separation: CoreCI owns the pipeline, Gitea Actions owns the trigger + container publish | 0.95 |
|
||||
|
||||
## Research: CoreCI podman executor entrypoint issue
|
||||
|
||||
CoreCI's `internal/runner/podman_executor.go:48-51`:
|
||||
```go
|
||||
args = append(args, image) // e.g. gcr.io/kaniko-project/executor:debug
|
||||
if job.Invoke != "" {
|
||||
args = append(args, "sh", "-c", job.Invoke)
|
||||
}
|
||||
```
|
||||
This produces: `podman run ... <image> sh -c "<commands>"`
|
||||
With kaniko:debug (entrypoint `/kaniko/executor`), the actual command is:
|
||||
`/kaniko/executor sh -c "<commands>"` — kaniko fails (sh is not a kaniko flag).
|
||||
|
||||
**Conclusion**: kaniko cannot be used as a CoreCI step image. Container
|
||||
publishing must move to the Gitea Actions workflow, which supports
|
||||
`container: options: --entrypoint /bin/sh` to override the entrypoint.
|
||||
|
||||
## Plan
|
||||
|
||||
### Phase 1 (only execution phase)
|
||||
|
||||
**Files to create/modify:**
|
||||
|
||||
1. `.gitea/workflows/release.yml` — Gitea Actions workflow:
|
||||
- `on: push: tags: ['v*']`
|
||||
- Job 1 `ci`: checkout + install Go + install coreci + `coreci run`
|
||||
(executes validate/build/test/release from .coreci.yml)
|
||||
- Job 2 `container-orca`: checkout + kaniko build+push orca image
|
||||
(needs job 1; uses `container: gcr.io/kaniko-project/executor:debug`
|
||||
with `options: --entrypoint /bin/sh`)
|
||||
- Job 3 `container-traefik`: checkout + kaniko build+push orca-traefik image
|
||||
(needs job 1; same kaniko approach)
|
||||
|
||||
2. `.coreci.yml` — remove `container-publish` and `container-publish-traefik`
|
||||
steps (they now live in the Gitea Actions workflow). Keep the
|
||||
`gitea-release` step (tarball + Gitea release).
|
||||
|
||||
3. `scripts/trigger_coreci.sh` — add tag ref handling (or document that
|
||||
Gitea Actions is the trigger; the hook is for branch-push CI only).
|
||||
@@ -0,0 +1,117 @@
|
||||
# CLARIFY v0.16: Release Binary Asset Fix
|
||||
|
||||
## Decisions
|
||||
|
||||
| ID | Decision | Rationale | Confidence |
|
||||
|----|----------|-----------|------------|
|
||||
| D-269 | Auth the coreci clone via URL embedding | The `actions/checkout@v4` step injects auth only for the orca repo. The bare `git clone https://git.cloudinit.dev/coreci/coreci.git` has no credentials and fails with `fatal: could not read Username`. Embedding `https://cloudinit-bot:${GITEA_TOKEN}@git.cloudinit.dev/...` in the clone URL is the simplest fix — no git credential helper config needed. | 0.95 |
|
||||
| D-270 | Rewrite .coreci.yml to CoreCI native `jobs:` format | CoreCI's `Pipeline` struct (`workflows/pipeline/pipeline.go`) only has `Jobs`/`Services`/`Env` fields. The orca `.coreci.yml` uses `pipelines:`/`steps:`/`image:`/`commands:` which are silently dropped by `yaml.Unmarshal` → empty `Jobs` map → zero jobs execute. `validate()` does not reject empty jobs. | 0.97 (validated against CoreCI source) |
|
||||
| D-271 | No tag-conditional rules in .coreci.yml | The Gitea Actions workflow already gates on `on: push: tags: ['v*']`. Every `coreci run` invocation is already a release run. CoreCI's `cicontext/github.go` doesn't even set `CI_COMMIT_TAG` for Gitea Actions (it maps `GITHUB_REF_NAME` → `CI_COMMIT_BRANCH`). | 0.90 |
|
||||
| D-272 | Use `CI_COMMIT_BRANCH` for tag name | On a tag push, Gitea Actions sets `GITHUB_REF_NAME=v0.15.1`. CoreCI's `github.go` maps this to `CI_COMMIT_BRANCH`. So `CI_COMMIT_BRANCH` contains the tag name on tag pushes. This is the env var to use for version injection in `invoke:` scripts. | 0.90 |
|
||||
| D-273 | Handle duplicate release gracefully | The CIAgent ship workflow creates releases (title+body, no binary) via the Gitea API. The `coreci run` release job runs later (after the Gitea Actions workflow triggers). `tea releases create` fails if the release exists. Fallback: query the release ID by tag and attach assets via the Gitea API `POST /releases/{id}/assets` endpoint. | 0.92 |
|
||||
| D-274 | Shell-friendly jobs (no `apk add`) | The Gitea Actions runner runs the `ci` job inside `docker.gitea.com/runner-images:ubuntu-latest` (ubuntu, not alpine). CoreCI's shell-isolated executor (the likely fallback if podman/docker aren't in the runner container) runs `sh -c <invoke>` directly. `apk add` won't work on ubuntu. Use `curl` (pre-installed) for tool downloads. | 0.85 |
|
||||
| D-275 | `GITEA_TOKEN` via PassThroughEnv | CoreCI's `PassThroughEnv()` forwards env vars not in the deny-list. `GITEA_TOKEN` is not in `systemVars` or `predefinedCIVars`, so it IS forwarded when `IsRunningInCI()` is true (Gitea Actions sets `GITHUB_ACTIONS=true`). The Gitea Actions workflow sets `GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}` in the `coreci run` step env. So `GITEA_TOKEN` is available in job `invoke:` scripts. Belt-and-suspenders: also declare `vars: { GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }} }` so CoreCI's secret resolver picks it up via `os.Getenv` fallback. | 0.88 |
|
||||
|
||||
## Research: CoreCI .coreci.yml format (validated against source)
|
||||
|
||||
CoreCI's `Pipeline` struct (`workflows/pipeline/pipeline.go`):
|
||||
```go
|
||||
type Pipeline struct {
|
||||
Jobs map[string]Job `yaml:"jobs"`
|
||||
Services map[string]Service `yaml:"services,omitempty"`
|
||||
Env EnvBlock `yaml:"env,omitempty"`
|
||||
}
|
||||
type Job struct {
|
||||
Needs []string `yaml:"needs,omitempty"`
|
||||
Plugin string `yaml:"plugin,omitempty"`
|
||||
Invoke string `yaml:"invoke,omitempty"`
|
||||
Vars map[string]string `yaml:"vars,omitempty"`
|
||||
MemoryLimitMb int `yaml:"memory_limit_mb,omitempty"`
|
||||
TimeoutMs int `yaml:"timeout_ms,omitempty"`
|
||||
Rules []Rule `yaml:"rules,omitempty"`
|
||||
Tags []string `yaml:"tags,omitempty"`
|
||||
}
|
||||
```
|
||||
|
||||
Key facts (from `docs/CORECI-YML.md` + source):
|
||||
- `plugin` and `invoke` are mutually exclusive on the same job — BUT the
|
||||
isolated_shell executor checks `invoke` first (line 52) and only falls
|
||||
back to `plugin` if `invoke` is empty. So a job with BOTH `plugin:
|
||||
docker://golang:1.25` AND `invoke: "go build ..."` works: container
|
||||
executors run the invoke inside the container; shell-isolated runs
|
||||
the invoke directly (ignoring the image). This is the correct pattern.
|
||||
- Unknown YAML fields are silently dropped (no strict decode). This is
|
||||
why the current `pipelines:`/`steps:`/`image:`/`commands:` format
|
||||
produces an empty `Jobs` map with no error.
|
||||
- `validate()` does NOT reject empty `Jobs` maps — it only checks for
|
||||
duplicate names and plugin/invoke mutual exclusivity within existing
|
||||
jobs.
|
||||
- Secret interpolation `${{ secrets.KEY }}` works only in job `vars:`
|
||||
values. The resolver (run.go:146-153) checks the local secret store
|
||||
first, then falls back to `os.Getenv(key)`.
|
||||
- Shell `${VAR}` expansion works inside `invoke:` strings at runtime
|
||||
(via `sh -c`), but NOT in YAML field values at parse time.
|
||||
- `env.from_ci` controls which CI vars are injected; if empty, all
|
||||
detected CI vars are merged.
|
||||
|
||||
## Research: Gitea Actions runner environment
|
||||
|
||||
The `ci` job (no `container:` field) runs inside
|
||||
`docker.gitea.com/runner-images:ubuntu-latest`. The `Set up Go` step
|
||||
installs Go 1.25. CoreCI's executor chain is `podman,docker,shell-isolated`.
|
||||
If podman/docker aren't in the runner container, jobs fall back to
|
||||
`shell-isolated` which runs `sh -c <invoke>` directly. Go commands work
|
||||
in shell-isolated mode (Go is on PATH). Tool installation via `go install`
|
||||
works (needs Go + network). `gitleaks` binary download via `curl` works.
|
||||
|
||||
## Research: Gitea Actions CI context (CoreCI detection)
|
||||
|
||||
CoreCI's `cicontext/github.go`:
|
||||
```go
|
||||
func isGitHub() bool { return os.Getenv("GITHUB_ACTIONS") == "true" }
|
||||
func normalizeGitHub() map[string]string {
|
||||
return map[string]string{
|
||||
"CI": "true",
|
||||
"CI_COMMIT_SHA": envOrDefault("GITHUB_SHA", ""),
|
||||
"CI_COMMIT_BRANCH": envOrDefault("GITHUB_REF_NAME", ""),
|
||||
// ... (no CI_COMMIT_TAG)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
On a tag push: `GITHUB_REF_NAME=v0.15.1` → `CI_COMMIT_BRANCH=v0.15.1`.
|
||||
`CI_COMMIT_TAG` is NOT set — CoreCI doesn't populate it for Gitea Actions.
|
||||
|
||||
## Plan
|
||||
|
||||
### Phase 1 (only execution phase)
|
||||
|
||||
**Files to modify:**
|
||||
|
||||
1. `.gitea/workflows/release.yml` — move `GITEA_TOKEN` env to the
|
||||
"Install CoreCI" step and embed it in the clone URL:
|
||||
```yaml
|
||||
- name: Install CoreCI
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}
|
||||
run: |
|
||||
git clone --depth=1 https://cloudinit-bot:${GITEA_TOKEN}@git.cloudinit.dev/coreci/coreci.git /tmp/coreci
|
||||
cd /tmp/coreci
|
||||
CGO_ENABLED=0 go build -tags sqlite_go,embed -o /usr/local/bin/coreci ./cmd/coreci
|
||||
coreci version
|
||||
```
|
||||
|
||||
2. `.coreci.yml` — full rewrite to CoreCI native `jobs:` format:
|
||||
- DAG: `go-vet` → fan-out to `verify-reqs`, `gosec`, `govulncheck`,
|
||||
`gitleaks` → `build` → `test` → `release`
|
||||
- Each job: `plugin: docker://golang:1.25.12` + `invoke: |` (multi-line)
|
||||
- `build` job: version injection via `CI_COMMIT_BRANCH` (tag) +
|
||||
`CI_COMMIT_SHA` + `date` for build time
|
||||
- `release` job: build tarball + SHA256SUMS, install `tea` via curl,
|
||||
create release with assets (fallback to API asset attachment if
|
||||
release exists), verify asset count ≥ 2 (REQ-097 gate C-21)
|
||||
- `GITEA_TOKEN` via `vars: { GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }} }`
|
||||
- No tag-conditional rules (workflow already gates on tags)
|
||||
|
||||
3. `scripts/trigger_coreci.sh` — no changes needed (Gitea Actions is the
|
||||
trigger; the hook is for branch-push CI only).
|
||||
@@ -0,0 +1,84 @@
|
||||
# PLAN v0.16: Release Binary Asset Fix
|
||||
|
||||
## Milestone Summary
|
||||
|
||||
**Milestone**: v0.16 (fix type — tags on v0.15.x patch line)
|
||||
**Phases**: P0 (pre-execution) → P1 (fix) → P2 (final review+ship)
|
||||
**Requirements**: REQ-183 (clone auth), REQ-184 (.coreci.yml rewrite)
|
||||
|
||||
## Phase 1: Fix Gitea Actions clone auth + rewrite .coreci.yml
|
||||
|
||||
### Wave 1: Both fixes (single wave — they are independent files)
|
||||
|
||||
**Task 1.1 (REQ-183): Fix `.gitea/workflows/release.yml` — auth the coreci clone**
|
||||
|
||||
File: `.gitea/workflows/release.yml`
|
||||
|
||||
Current failing step:
|
||||
```yaml
|
||||
- name: Install CoreCI
|
||||
run: |
|
||||
git clone --depth=1 https://git.cloudinit.dev/coreci/coreci.git /tmp/coreci
|
||||
cd /tmp/coreci
|
||||
CGO_ENABLED=0 go build -tags sqlite_go,embed -o /usr/local/bin/coreci ./cmd/coreci
|
||||
coreci version
|
||||
```
|
||||
|
||||
Fix: add `GITEA_TOKEN` env and embed in clone URL:
|
||||
```yaml
|
||||
- name: Install CoreCI
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}
|
||||
run: |
|
||||
git clone --depth=1 https://cloudinit-bot:${GITEA_TOKEN}@git.cloudinit.dev/coreci/coreci.git /tmp/coreci
|
||||
cd /tmp/coreci
|
||||
CGO_ENABLED=0 go build -tags sqlite_go,embed -o /usr/local/bin/coreci ./cmd/coreci
|
||||
coreci version
|
||||
```
|
||||
|
||||
**Task 1.2 (REQ-184): Rewrite `.coreci.yml` to CoreCI native `jobs:` format**
|
||||
|
||||
File: `.coreci.yml`
|
||||
|
||||
Convert from `pipelines:`/`steps:`/`image:`/`commands:` to `jobs:`/`plugin:`/`invoke:`/`vars:` with a DAG.
|
||||
|
||||
DAG structure:
|
||||
```
|
||||
go-vet ──→ verify-reqs ──┐
|
||||
├──→ gosec ────────┤
|
||||
├──→ govulncheck ──┤──→ build ──→ test ──→ release
|
||||
└──→ gitleaks ─────┘
|
||||
```
|
||||
|
||||
Key adaptations:
|
||||
- `plugin: docker://golang:1.25.12` on each job (container if available, shell-isolated fallback)
|
||||
- `invoke: |` for multi-line commands (shell expansion works via `sh -c`)
|
||||
- `GITEA_TOKEN` via `vars: { GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }} }` (resolved from env)
|
||||
- `CI_COMMIT_BRANCH` (tag name on tag push) and `CI_COMMIT_SHA` for version injection
|
||||
- No tag-conditional rules (workflow gates on `on: push: tags: ['v*']`)
|
||||
- `release` job: build tarball + SHA256SUMS, install tea via curl, create release
|
||||
with assets (fallback to Gitea API asset attachment if release exists),
|
||||
verify asset count ≥ 2 (REQ-097 gate C-21)
|
||||
- No `apk add` (runner is ubuntu, not alpine)
|
||||
|
||||
### Must-haves (verification gates)
|
||||
|
||||
- [ ] `.gitea/workflows/release.yml` "Install CoreCI" step has `GITEA_TOKEN` env and token in clone URL
|
||||
- [ ] `.coreci.yml` uses `jobs:` top-level key (not `pipelines:`)
|
||||
- [ ] Each job has `plugin:` and/or `invoke:` (mutually exclusive rule)
|
||||
- [ ] DAG via `needs:` (validate → build → test → release)
|
||||
- [ ] `GITEA_TOKEN` passed via job `vars:` with `${{ secrets.GITEA_TOKEN }}`
|
||||
- [ ] Release job handles duplicate release (fallback to API asset attachment)
|
||||
- [ ] Release job verifies asset count ≥ 2 (REQ-097)
|
||||
- [ ] No `apk add` commands (ubuntu runner, not alpine)
|
||||
- [ ] No `${VAR}` interpolation in YAML fields (only in `invoke:` via sh -c)
|
||||
- [ ] `make verify-reqs` passes (ROADMAP ↔ REQUIREMENTS consistency)
|
||||
|
||||
### Verification
|
||||
|
||||
1. `make verify-reqs` — ROADMAP/REQUIREMENTS consistency
|
||||
2. `go vet ./...` — no vet errors
|
||||
3. `gofmt -l .` — no formatting issues
|
||||
4. YAML validity check for `.coreci.yml` and `.gitea/workflows/release.yml`
|
||||
5. Confirm `.coreci.yml` has `jobs:` key and at least 5 jobs (go-vet, verify-reqs, gosec, govulncheck, gitleaks, build, test, release)
|
||||
6. Confirm `.gitea/workflows/release.yml` "Install CoreCI" step references `GITEA_TOKEN`
|
||||
@@ -427,3 +427,55 @@ node type.
|
||||
- 9 phases (P0 + P1..P7 + P8 final); feature milestone (multiple `feat` phases).
|
||||
- Tags on v0.13.x patch line: `v0.13.0` (P0) ... `v0.13.8` (P8 final = v0.14 milestone release).
|
||||
- Milestone branch: `milestone/v0.14-ingress-bootstrap`.
|
||||
|
||||
## Milestone v0.15: CI Release Pipeline Fix
|
||||
|
||||
**Scope**: fix the container image publishing pipeline. v0.14 shipped
|
||||
`Dockerfile.traefik` + `Dockerfile` but no container images were
|
||||
published to the Gitea registry because: (1) no Gitea Actions workflow
|
||||
existed to trigger on tag pushes, (2) the CoreCI trigger script
|
||||
stripped tag refs, (3) the `.coreci.yml` container-publish steps used
|
||||
Docker-in-Docker (`docker:24-cli`) which is prohibited. v0.15 adds a
|
||||
Gitea Actions workflow that triggers on tag pushes, installs the
|
||||
`coreci` binary on the runner, and runs `coreci run`. The
|
||||
`.coreci.yml` container-publish steps are rewritten to use kaniko
|
||||
(no Docker daemon required).
|
||||
|
||||
| ID | Requirement | Priority | Phase | Status |
|
||||
|----|-------------|----------|-------|--------|
|
||||
| REQ-180 | Create `.gitea/workflows/release.yml` that triggers on `push: tags: ['v*']`, installs the `coreci` binary (from `git.cloudinit.dev/coreci/coreci`), injects `PAT_TOKEN` secret as `GITEA_TOKEN` env var, and runs `coreci run` — which executes the full `.coreci.yml` pipeline (validate, build, test, release) locally on the Gitea Actions runner | Critical | **v0.15 P1** | complete |
|
||||
| REQ-181 | Replace `docker:24-cli` DinD steps in `.coreci.yml` with kaniko (`gcr.io/kaniko-project/executor:debug`): write `/kaniko/.docker/config.json` from `GITEA_TOKEN` (base64 auth), run `/kaniko/executor --dockerfile=<Dockerfile> --context=dir://. --destination=<registry/image:tag> --skip-tls-verify-registry`. Applies to both `container-publish` (orca image) and `container-publish-traefik` (orca-traefik image) | Critical | **v0.15 P1** | complete |
|
||||
| REQ-182 | Set `PAT_TOKEN` Gitea Actions repository secret via `tea actions secrets create` (same value as `GITEA_TOKEN` from `.env`). Gitea reserves the `GITEA_` prefix for built-in secrets, so the secret must be named `PAT_TOKEN`, not `GITEA_PAT` | High | **v0.15 P0** | complete |
|
||||
|
||||
### Scope notes (v0.15)
|
||||
|
||||
- REQ-180..REQ-182 = 3 net-new requirements (REQ count grows 172 -> 175).
|
||||
- 3 phases (P0 + P1 + P2 final); fix milestone (no `feat` phases — CI infrastructure).
|
||||
- Tags on v0.14.x patch line: `v0.14.0` (P0) ... `v0.14.2` (P2 final = v0.15 milestone release).
|
||||
- Milestone branch: `milestone/v0.15-ci-release-pipeline`.
|
||||
- REQ-182 is complete: `PAT_TOKEN` secret created via `tea actions secrets create PAT_TOKEN <value> --repo coreci/orca`.
|
||||
|
||||
## Milestone v0.16: Release Binary Asset Fix
|
||||
|
||||
**Scope**: fix the root cause of releases shipping with zero binary
|
||||
assets. v0.15 added a Gitea Actions workflow but it never executed
|
||||
successfully due to two compounding bugs: (1) the `git clone` of the
|
||||
private `coreci` repo in the workflow had no credentials, causing the
|
||||
"Install CoreCI" step to fail; (2) the `.coreci.yml` used an invalid
|
||||
`pipelines:`/`steps:`/`image:`/`commands:` format that CoreCI does not
|
||||
recognize (CoreCI's native format is `jobs:` with `plugin:`/`invoke:`
|
||||
/`vars:` and a DAG via `needs:`). Both issues must be fixed for the
|
||||
release pipeline to actually build and upload binaries.
|
||||
|
||||
| ID | Requirement | Priority | Phase | Status |
|
||||
|----|-------------|----------|-------|--------|
|
||||
| REQ-183 | Fix `.gitea/workflows/release.yml` "Install CoreCI" step: the `git clone` of the private `coreci` repo fails because the clone command has no credentials. The `actions/checkout@v4` step only injects auth for the orca repo (via `http.https://git.cloudinit.dev/.extraheader`), not for the subsequent bare `git clone` of the coreci repo. Fix: embed the `PAT_TOKEN` in the clone URL (`https://cloudinit-bot:${GITEA_TOKEN}@git.cloudinit.dev/coreci/coreci.git`) and pass `GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}` as env to the "Install CoreCI" step | Critical | **v0.16 P1** | pending |
|
||||
| REQ-184 | Rewrite `.coreci.yml` from the invalid `pipelines:`/`steps:`/`image:`/`commands:` format to CoreCI's native `jobs:`/`plugin:`/`invoke:`/`vars:` format with a proper DAG (`needs:`). CoreCI's `Pipeline` struct only has `Jobs`/`Services`/`Env` fields — unknown top-level keys and unknown job fields are silently dropped by `yaml.Unmarshal`, producing an empty `Jobs` map. `coreci run` then executes zero jobs (validate does not reject empty jobs). The rewrite must: (a) convert each pipeline to a job with `plugin: docker://golang:1.25.12` and `invoke:` for the commands, (b) use `needs:` for DAG ordering (validate→build→test→release), (c) pass `GITEA_TOKEN` via `vars: { GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }} }` (resolved from env via CoreCI's secret resolver `os.Getenv` fallback), (d) use `CI_COMMIT_BRANCH` (tag name on tag push, from CoreCI's github.go CI context) and `CI_COMMIT_SHA` for version injection, (e) handle the case where the release already exists (created by the CIAgent ship workflow with title+body but no binary) by falling back to Gitea API asset attachment, (f) verify assets are actually attached after release creation (REQ-097 gate C-21) | Critical | **v0.16 P1** | pending |
|
||||
|
||||
### Scope notes (v0.16)
|
||||
|
||||
- REQ-183..REQ-184 = 2 net-new requirements (REQ count grows 175 -> 177).
|
||||
- 3 phases (P0 + P1 + P2 final); fix milestone (no `feat` phases — CI infrastructure).
|
||||
- Tags on v0.15.x patch line: `v0.15.0` (P0) ... `v0.15.2` (P2 final = v0.16 milestone release).
|
||||
- Milestone branch: `milestone/v0.16-release-binary-fix`.
|
||||
- Root cause analysis confirmed: all 87 releases in the repo's history have zero binary assets — this has never worked. The releases are created by the CIAgent ship workflow (via Gitea API, title+body only); the binary upload is exclusively the `.coreci.yml` release job's job, and that job has never executed.
|
||||
|
||||
@@ -0,0 +1,159 @@
|
||||
# RESEARCH v0.16: Release Binary Asset Fix
|
||||
|
||||
## Root Cause: Two Compounding Bugs
|
||||
|
||||
### Bug 1: Gitea Actions workflow cannot clone private coreci repo
|
||||
|
||||
`.gitea/workflows/release.yml` step "Install CoreCI" runs:
|
||||
```bash
|
||||
git clone --depth=1 https://git.cloudinit.dev/coreci/coreci.git /tmp/coreci
|
||||
```
|
||||
|
||||
The `coreci` repo is **private** (confirmed: `curl -s -o /dev/null -w "%{http_code}" https://git.cloudinit.dev/coreci/coreci` returns 404 without auth; the Gitea API reports `"private": true`).
|
||||
|
||||
The `actions/checkout@v4` step injects auth only for the orca repo:
|
||||
```
|
||||
[command]/usr/bin/git config --local http.https://git.cloudinit.dev/.extraheader AUTHORIZATION: basic ***
|
||||
```
|
||||
|
||||
The subsequent bare `git clone` of the coreci repo has no credentials. Runner logs confirm the failure:
|
||||
```
|
||||
fatal: could not read Username for 'https://git.cloudinit.dev': No such device or address
|
||||
❌ Failure - Main Install CoreCI
|
||||
exitcode '128': failure
|
||||
```
|
||||
|
||||
Both Gitea Actions runs (v0.14.1 run #3540, v0.14.2 run #3544) failed at this step. The `container-orca` and `container-traefik` jobs (with `needs: ci`) were skipped. `coreci run` never executed.
|
||||
|
||||
**Fix (REQ-183):** Pass `GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}` as env to the "Install CoreCI" step and embed it in the clone URL:
|
||||
```bash
|
||||
git clone --depth=1 https://cloudinit-bot:${GITEA_TOKEN}@git.cloudinit.dev/coreci/coreci.git /tmp/coreci
|
||||
```
|
||||
|
||||
### Bug 2: .coreci.yml uses a format CoreCI does not understand
|
||||
|
||||
The orca `.coreci.yml` uses:
|
||||
```yaml
|
||||
pipelines:
|
||||
validate:
|
||||
steps:
|
||||
- name: go-version
|
||||
image: golang:1.25.12
|
||||
commands: [go version, gofmt -l ., go vet ./...]
|
||||
release:
|
||||
when:
|
||||
ref: "refs/tags/v*"
|
||||
steps: [...]
|
||||
```
|
||||
|
||||
CoreCI's actual format (validated against `workflows/pipeline/pipeline.go`):
|
||||
```go
|
||||
type Pipeline struct {
|
||||
Jobs map[string]Job `yaml:"jobs"`
|
||||
Services map[string]Service `yaml:"services,omitempty"`
|
||||
Env EnvBlock `yaml:"env,omitempty"`
|
||||
}
|
||||
type Job struct {
|
||||
Needs []string `yaml:"needs,omitempty"`
|
||||
Plugin string `yaml:"plugin,omitempty"`
|
||||
Invoke string `yaml:"invoke,omitempty"`
|
||||
Vars map[string]string `yaml:"vars,omitempty"`
|
||||
// ...
|
||||
}
|
||||
```
|
||||
|
||||
`yaml.Unmarshal` into a struct silently drops unknown fields (no `KnownFields(true)`). The `pipelines:` top-level key doesn't map to any struct field → `Jobs` is an empty map. CoreCI's `validate()` does NOT reject empty jobs:
|
||||
```go
|
||||
func validate(p *Pipeline) error {
|
||||
seen := make(map[string]struct{}, len(p.Jobs))
|
||||
for name, job := range p.Jobs { ... }
|
||||
return nil // empty Jobs → no iterations → nil error
|
||||
}
|
||||
```
|
||||
|
||||
So `coreci run` loads an empty pipeline, runs zero jobs, and exits successfully — no build, no tarball, no asset upload.
|
||||
|
||||
Additional format mismatches in the current `.coreci.yml`:
|
||||
- `when: ref: "refs/tags/v*"` — CoreCI has no `when` at pipeline/job level; it uses `rules: [{if: "CI_COMMIT_TAG"}]` on jobs. And CoreCI's `github.go` doesn't set `CI_COMMIT_TAG` for Gitea Actions. But the Gitea Actions workflow already gates on `on: push: tags: ['v*']`, so no conditional is needed.
|
||||
- `${CI_COMMIT_TAG:-dev}` in `env:` blocks — CoreCI does not expand `${VAR}` at YAML parse time. Only `${{ secrets.KEY }}` is interpolated. Shell expansion works inside `invoke:` via `sh -c`.
|
||||
- `GITEA_TOKEN: ${GITEA_TOKEN}` in `env:` blocks — CoreCI's `env` block doesn't do env-var interpolation. Secrets must go in job `vars:` via `${{ secrets.GITEA_TOKEN }}`.
|
||||
|
||||
**Fix (REQ-184):** Full rewrite to CoreCI native `jobs:` format with a proper DAG.
|
||||
|
||||
## CoreCI Execution Model (validated against source)
|
||||
|
||||
### Executor Chain
|
||||
Default: `podman,docker,shell-isolated` (`NewChainExecutorFromConfig`).
|
||||
- `ErrExecutorUnavailable` (executor missing) → fall through to next.
|
||||
- `ErrExecutorFailed` (non-zero exit) → stop immediately, no fallback.
|
||||
|
||||
### Job Execution with `plugin` + `invoke`
|
||||
A job with BOTH `plugin: docker://golang:1.25` AND `invoke: "go build ..."`:
|
||||
- **Podman/Docker executor**: pulls image, runs `podman/docker run ... <image> sh -c "<invoke>"`. Env vars from the `env` map are injected via `-e K=V`.
|
||||
- **Shell-isolated executor**: checks `invoke` first (line 52). If non-empty, runs `sh -c "<invoke>"` directly, ignoring the `plugin` image. This is the fallback when no container runtime is available.
|
||||
- This dual pattern is correct: container if available, shell fallback if not.
|
||||
|
||||
### Environment Variables in Jobs
|
||||
`buildIsolatedEnv` (`isolated_shell.go:34`):
|
||||
```go
|
||||
func buildIsolatedEnv(env map[string]string) []string {
|
||||
var out []string
|
||||
for _, key := range envAllowlist { // PATH, HOME, LANG, TMPDIR, TERM, CI
|
||||
if val, ok := os.LookupEnv(key); ok { out = append(out, ...) }
|
||||
}
|
||||
for _, kv := range os.Environ() {
|
||||
if strings.HasPrefix(kv, "CORECI_") || strings.HasPrefix(kv, "CI_") { out = append(out, kv) }
|
||||
}
|
||||
for k, v := range env { out = append(out, fmt.Sprintf("%s=%s", k, v)) } // env map
|
||||
out = append(out, "CORECI_SANDBOX=isolated-shell")
|
||||
return out
|
||||
}
|
||||
```
|
||||
|
||||
The `env` map (3rd loop) is built in `run.go` from:
|
||||
1. `cicontext.Detect()` → CI context (`CI_COMMIT_SHA`, `CI_COMMIT_BRANCH`, etc.)
|
||||
2. `envfwd.PassThroughEnv()` → user-defined host env vars NOT in deny-list
|
||||
3. Job `vars` (with `${{ secrets.* }}` interpolation)
|
||||
|
||||
So in a job's `invoke:` script, these env vars are available:
|
||||
- `CI_COMMIT_BRANCH` — tag name on tag push (from `GITHUB_REF_NAME`)
|
||||
- `CI_COMMIT_SHA` — commit SHA
|
||||
- `GITEA_TOKEN` — forwarded by PassThroughEnv (not in deny-list)
|
||||
- `CORECI_*` prefixed vars — always forwarded
|
||||
- `CI_*` prefixed vars — always forwarded
|
||||
- Any job `vars` values
|
||||
|
||||
### Secret Resolution
|
||||
`run.go:146-153`:
|
||||
```go
|
||||
resolver := func(key string) (string, error) {
|
||||
if v, ok := secretMap[key]; ok { return v, nil } // local DB first
|
||||
if v := os.Getenv(key); v != "" { return v, nil } // then env
|
||||
return "", secrets.ErrMissingKey
|
||||
}
|
||||
```
|
||||
Secret interpolation `${{ secrets.GITEA_TOKEN }}` in job `vars:` is resolved by checking the local CoreCI secret store first, then `os.Getenv`. Since `GITEA_TOKEN` is in the env (from the Gitea Actions step env), `os.Getenv("GITEA_TOKEN")` succeeds.
|
||||
|
||||
## Gitea Actions CI Context
|
||||
|
||||
On a tag push (`refs/tags/v0.15.1`), Gitea Actions sets:
|
||||
- `GITHUB_ACTIONS=true`
|
||||
- `GITHUB_REF=refs/tags/v0.15.1`
|
||||
- `GITHUB_REF_NAME=v0.15.1`
|
||||
- `GITHUB_REF_TYPE=tag`
|
||||
- `GITHUB_SHA=<commit>`
|
||||
|
||||
CoreCI's `github.go` maps:
|
||||
- `GITHUB_ACTIONS=true` → `isGitHub()` returns true → `IsRunningInCI()` true
|
||||
- `GITHUB_SHA` → `CI_COMMIT_SHA`
|
||||
- `GITHUB_REF_NAME` → `CI_COMMIT_BRANCH` (= `v0.15.1` on tag push)
|
||||
|
||||
`PassThroughEnv()` runs (CI detected). `GITHUB_REF` is in `predefinedCIVars` (NOT forwarded), but `GITEA_TOKEN` is NOT in any deny-list → forwarded.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The fix is two file changes:
|
||||
1. `.gitea/workflows/release.yml` — auth the coreci clone (embed token in URL)
|
||||
2. `.coreci.yml` — rewrite to CoreCI native `jobs:` format with DAG
|
||||
|
||||
Both are validated against CoreCI source code and docs. No API calls needed — `coreci run` executes the `.coreci.yml` pipeline locally on the runner.
|
||||
@@ -729,3 +729,41 @@ is unchanged. v0.14 completes the ingress bootstrap that v0.13 left
|
||||
non-functional (binary installed but no config, no nft applied). The
|
||||
podman-container model is the operator's constraint; the architecture's
|
||||
socket+traefik routing design (R-007, R-017) is unchanged.
|
||||
|
||||
## Milestone v0.15: CI Release Pipeline Fix — **COMPLETE**
|
||||
|
||||
**Scope**: fix container image publishing. v0.14 shipped
|
||||
`Dockerfile.traefik` + `Dockerfile` but no images were published
|
||||
because no Gitea Actions workflow triggered on tag pushes, and
|
||||
`.coreci.yml` used Docker-in-Docker. v0.15 adds a Gitea Actions
|
||||
workflow (trigger on tag push → install coreci → `coreci run`) and
|
||||
rewrites the container-publish steps to use kaniko (no DinD).
|
||||
|
||||
**Milestone type**: fix (CI infrastructure). Tags on v0.14.x patch
|
||||
line: `v0.14.0` (P0) ... `v0.14.2` (P2 final = v0.15 milestone release).
|
||||
|
||||
- [x] Phase 0: Pre-execution (SPECIFY→CLARIFY→RESEARCH→PLAN→GRILL) — tag `v0.14.0`
|
||||
- [x] Phase 1: Gitea Actions workflow + .coreci.yml kaniko rewrite (REQ-180,181) — tag `v0.14.1`
|
||||
- [x] Phase 2: Final review + ship + audit (milestone release) — tag `v0.14.2` = **v0.15 milestone release**
|
||||
|
||||
## Milestone v0.16: Release Binary Asset Fix — **IN PROGRESS**
|
||||
|
||||
**Scope**: fix the root cause of releases shipping with zero binary
|
||||
assets. v0.15 added a Gitea Actions workflow but it never executed
|
||||
successfully: the `git clone` of the private `coreci` repo had no
|
||||
credentials (failed at "Install CoreCI"), and the `.coreci.yml` used an
|
||||
invalid `pipelines:`/`steps:`/`image:`/`commands:` format that CoreCI
|
||||
does not recognize (unknown fields silently dropped → empty `Jobs` map
|
||||
→ zero jobs executed). Both issues must be fixed for the release
|
||||
pipeline to actually build and upload binaries.
|
||||
|
||||
**Root cause (two compounding bugs):**
|
||||
1. `.gitea/workflows/release.yml` — `git clone https://git.cloudinit.dev/coreci/coreci.git` fails because the coreci repo is private and the clone has no credentials. The `actions/checkout@v4` step only injects auth for the orca repo.
|
||||
2. `.coreci.yml` — uses `pipelines:` with `steps:`/`image:`/`commands:`, but CoreCI's native format is `jobs:` with `plugin:`/`invoke:`/`vars:` and a DAG via `needs:`. YAML unmarshal into CoreCI's `Pipeline` struct silently drops unknown fields, producing an empty `Jobs` map. `coreci run` executes zero jobs — no build, no tarball, no asset upload.
|
||||
|
||||
**Milestone type**: fix (CI infrastructure). Tags on v0.15.x patch
|
||||
line: `v0.15.0` (P0) ... `v0.15.2` (P2 final = v0.16 milestone release).
|
||||
|
||||
- [ ] Phase 0: Pre-execution (SPECIFY→CLARIFY→RESEARCH→PLAN→GRILL) — tag `v0.15.0`
|
||||
- [ ] Phase 1: Fix Gitea Actions clone auth + rewrite .coreci.yml to CoreCI native format (REQ-183,184) — tag `v0.15.1`
|
||||
- [ ] Phase 2: Final review + ship + audit (milestone release) — tag `v0.15.2` = **v0.16 milestone release**
|
||||
|
||||
@@ -5,9 +5,9 @@
|
||||
"slug": "orca",
|
||||
"name": "Orca",
|
||||
"description": "Offline/CLI-first orchestration engine (Orca) \u2014 Nomad-inspired, far simpler than Kubernetes",
|
||||
"milestone": "v0.14",
|
||||
"milestone": "v0.16",
|
||||
"phase": 0,
|
||||
"milestone_type": "feature",
|
||||
"milestone_type": "fix",
|
||||
"default_branch": "main",
|
||||
"tech_stack": {
|
||||
"language": "go",
|
||||
|
||||
-36
@@ -147,39 +147,3 @@ pipelines:
|
||||
-F "attachment=@SHA256SUMS"
|
||||
fi
|
||||
fi
|
||||
- name: container-publish
|
||||
description: Build and publish OCI image to Gitea container registry (REQ-046)
|
||||
image: docker:24-cli
|
||||
env:
|
||||
GITEA_TOKEN: ${GITEA_TOKEN}
|
||||
VERSION: ${CI_COMMIT_TAG}
|
||||
GIT_COMMIT: ${CI_COMMIT_SHA}
|
||||
BUILD_TIME: ${CI_BUILD_TIME}
|
||||
commands:
|
||||
- docker build
|
||||
--build-arg VERSION=${VERSION}
|
||||
--build-arg GIT_COMMIT=${GIT_COMMIT}
|
||||
--build-arg BUILD_TIME=${BUILD_TIME}
|
||||
-t git.cloudinit.dev/coreci/orca:${VERSION}
|
||||
-t git.cloudinit.dev/coreci/orca:latest
|
||||
.
|
||||
- echo "${GITEA_TOKEN}" | docker login git.cloudinit.dev -u cloudinit-bot --password-stdin
|
||||
- docker push git.cloudinit.dev/coreci/orca:${VERSION}
|
||||
- docker push git.cloudinit.dev/coreci/orca:latest
|
||||
- docker logout git.cloudinit.dev
|
||||
- name: container-publish-traefik
|
||||
description: Build and publish orca-traefik OCI image (REQ-171, R-024)
|
||||
image: docker:24-cli
|
||||
env:
|
||||
GITEA_TOKEN: ${GITEA_TOKEN}
|
||||
VERSION: ${CI_COMMIT_TAG}
|
||||
commands:
|
||||
- docker build
|
||||
-f Dockerfile.traefik
|
||||
-t git.cloudinit.dev/coreci/orca-traefik:${VERSION}
|
||||
-t git.cloudinit.dev/coreci/orca-traefik:latest
|
||||
.
|
||||
- echo "${GITEA_TOKEN}" | docker login git.cloudinit.dev -u cloudinit-bot --password-stdin
|
||||
- docker push git.cloudinit.dev/coreci/orca-traefik:${VERSION}
|
||||
- docker push git.cloudinit.dev/coreci/orca-traefik:latest
|
||||
- docker logout git.cloudinit.dev
|
||||
|
||||
@@ -0,0 +1,90 @@
|
||||
name: Release
|
||||
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- 'v*'
|
||||
|
||||
jobs:
|
||||
ci:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Set up Go
|
||||
uses: actions/setup-go@v5
|
||||
with:
|
||||
go-version: '1.25'
|
||||
|
||||
- name: Install CoreCI
|
||||
run: |
|
||||
git clone --depth=1 https://git.cloudinit.dev/coreci/coreci.git /tmp/coreci
|
||||
cd /tmp/coreci
|
||||
CGO_ENABLED=0 go build -tags sqlite_go,embed -o /usr/local/bin/coreci ./cmd/coreci
|
||||
coreci version
|
||||
|
||||
- name: Run CoreCI pipeline
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}
|
||||
run: |
|
||||
coreci run
|
||||
|
||||
container-orca:
|
||||
runs-on: ubuntu-latest
|
||||
needs: ci
|
||||
container:
|
||||
image: gcr.io/kaniko-project/executor:debug
|
||||
options: --entrypoint /bin/sh
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Build and push orca image
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}
|
||||
VERSION: ${{ gitea.ref_name }}
|
||||
run: |
|
||||
mkdir -p /kaniko/.docker
|
||||
AUTH=$(echo -n "cloudinit-bot:${GITEA_TOKEN}" | base64 -w0)
|
||||
echo "{\"auths\":{\"git.cloudinit.dev\":{\"auth\":\"${AUTH}\"}}}" > /kaniko/.docker/config.json
|
||||
GIT_COMMIT=$(echo -n "${{ gitea.sha }}" | cut -c1-12)
|
||||
BUILD_TIME=$(date -u +%Y-%m-%dT%H:%M:%SZ)
|
||||
/kaniko/executor \
|
||||
--dockerfile=Dockerfile \
|
||||
--context=dir://. \
|
||||
--destination=git.cloudinit.dev/coreci/orca:${VERSION} \
|
||||
--destination=git.cloudinit.dev/coreci/orca:latest \
|
||||
--build-arg=VERSION=${VERSION} \
|
||||
--build-arg=GIT_COMMIT=${GIT_COMMIT} \
|
||||
--build-arg=BUILD_TIME=${BUILD_TIME} \
|
||||
--skip-tls-verify-registry
|
||||
|
||||
container-traefik:
|
||||
runs-on: ubuntu-latest
|
||||
needs: ci
|
||||
container:
|
||||
image: gcr.io/kaniko-project/executor:debug
|
||||
options: --entrypoint /bin/sh
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
|
||||
- name: Build and push orca-traefik image
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.PAT_TOKEN }}
|
||||
VERSION: ${{ gitea.ref_name }}
|
||||
run: |
|
||||
if [ ! -f Dockerfile.traefik ]; then
|
||||
echo "Dockerfile.traefik not found at this tag — skipping orca-traefik image"
|
||||
exit 0
|
||||
fi
|
||||
mkdir -p /kaniko/.docker
|
||||
AUTH=$(echo -n "cloudinit-bot:${GITEA_TOKEN}" | base64 -w0)
|
||||
echo "{\"auths\":{\"git.cloudinit.dev\":{\"auth\":\"${AUTH}\"}}}" > /kaniko/.docker/config.json
|
||||
/kaniko/executor \
|
||||
--dockerfile=Dockerfile.traefik \
|
||||
--context=dir://. \
|
||||
--destination=git.cloudinit.dev/coreci/orca-traefik:${VERSION} \
|
||||
--destination=git.cloudinit.dev/coreci/orca-traefik:latest \
|
||||
--skip-tls-verify-registry
|
||||
@@ -164,6 +164,7 @@ if [ -z "$ASSET_URL" ]; then
|
||||
ASSET_URL="$(echo "$FALLBACK_OUT" | head -1)"
|
||||
if [ -n "$ASSET_URL" ]; then
|
||||
VERSION="$(echo "$FALLBACK_OUT" | tail -1)"
|
||||
TARBALL="orca-${VERSION}-${OS}-${ARCH}.tar.gz"
|
||||
info "WARNING: falling back to ${VERSION} which has orca-${VERSION}-${OS}-${ARCH}.tar.gz."
|
||||
else
|
||||
err "could not find any release with a ${OS}-${ARCH} tarball in the last 50 releases. Check that a release exists with a linux-${ARCH} binary."
|
||||
|
||||
@@ -39,6 +39,29 @@ load test_helper
|
||||
assert_contains "$output" "dry-run (--check)"
|
||||
}
|
||||
|
||||
@test "install.sh fallback walk syncs TARBALL to fallback version (REQ-132 regression)" {
|
||||
# Regression guard: when the fallback walk reassigns VERSION, the
|
||||
# TARBALL variable must be recomputed too. v0.14.2 is a release with
|
||||
# no binary asset; the installer must walk back to an earlier release.
|
||||
# The dry-run "would install" line must reference the SAME fallback
|
||||
# version as the "falling back to" line — not the stale pinned one.
|
||||
# Before the fix, TARBALL stayed at the pinned v0.14.2 name while
|
||||
# VERSION became the fallback, causing grep|sha256sum to see no
|
||||
# matching checksum line and REQ-132 to refuse install.
|
||||
skip_if_no_network
|
||||
run timeout 60 "$SCRIPTS_DIR/install.sh" --check --version v0.14.2
|
||||
assert_status 0 "$status"
|
||||
assert_contains "$output" "falling back"
|
||||
# Capture the fallback version from the "falling back to vX.Y.Z" line.
|
||||
fb_version="$(printf '%s\n' "$output" | sed -n 's/.*falling back to \(v[0-9][0-9.]*\).*/\1/p' | head -1)"
|
||||
[ -n "$fb_version" ] || { echo "could not parse fallback version from output: $output" >&2; return 1; }
|
||||
# The dry-run "would install" line must use the fallback version,
|
||||
# proving VERSION and TARBALL are in sync (not the stale pinned v0.14.2).
|
||||
assert_contains "$output" "would install: orca ${fb_version}"
|
||||
# And it must NOT reference the stale pinned version in the install line.
|
||||
assert_not_contains "$output" "would install: orca v0.14.2"
|
||||
}
|
||||
|
||||
@test "install.sh rejects unknown arguments" {
|
||||
run "$SCRIPTS_DIR/install.sh" --bogus-flag
|
||||
[ "$status" -ne 0 ]
|
||||
|
||||
@@ -30,6 +30,20 @@ fi
|
||||
while read local_ref local_sha remote_ref remote_sha; do
|
||||
branch="${remote_ref#refs/heads/}"
|
||||
if [ -z "$branch" ] || [ "$branch" = "HEAD" ]; then
|
||||
# Check if this is a tag push (refs/tags/*)
|
||||
tag="${remote_ref#refs/tags/}"
|
||||
if [ -n "$tag" ] && [ "$tag" != "$remote_ref" ]; then
|
||||
echo "→ Triggering CoreCI for tag: $tag (${local_sha:0:7})"
|
||||
payload=$(printf '{"repo":"coreci/orca","branch":"%s","ref":"%s"}' "$tag" "$local_sha")
|
||||
if command -v curl >/dev/null 2>&1; then
|
||||
curl -fsS -X POST "${CORECI_URL}/api/pipeline/run" \
|
||||
-H "Authorization: token ${GITEA_TOKEN}" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "$payload" >/dev/null 2>&1 \
|
||||
&& echo " ✓ CoreCI triggered" \
|
||||
|| echo " (CoreCI trigger failed; Gitea Actions webhook is secondary path)"
|
||||
fi
|
||||
fi
|
||||
continue
|
||||
fi
|
||||
echo "→ Triggering CoreCI for branch: $branch (${local_sha:0:7})"
|
||||
|
||||
Reference in New Issue
Block a user