## Summary Review session covering 3 docs, plus a codebase-wide cleanup: ### Docs reviewed - **connect-to-postgres** — verified end-to-end (psql connection tested), stamped - **create-release-artifact-workflow** — clarified that `build-blumeops.yaml` is only a version bump example (not a packages API example) - **deploy-k8s-service** — fixed stale repoURL (`indri:2200` → `forge.ops.eblu.me:2222`), wrong Caddy config keys (`upstream` → `backend`, added missing `host`), updated Homepage group to "Services", added Tailscale tag documentation ### Codebase cleanup - Migrated all remaining `op item get --fields` calls to `op read` URI syntax across 7 files (docs, READMEs, YAML comments) - Simplified the `op read` vs `op item get` guidance in CLAUDE.md ## Side findings (not addressed) - New `immich-pg` CNPG cluster not yet documented in the postgresql reference card ## Test plan - [x] `psql` connection to `pg.ops.eblu.me` verified - [x] All pre-commit hooks pass - [x] `docs-check-links`, `docs-check-index`, `docs-check-frontmatter` pass Reviewed-on: https://forge.ops.eblu.me/eblume/blumeops/pulls/191
2.5 KiB
| title | modified | last-reviewed | tags | |||
|---|---|---|---|---|---|---|
| Create Release Artifact Workflow | 2026-02-15 | 2026-02-15 |
|
Create a Release Artifact Workflow
How to set up a Forgejo Actions workflow that builds an artifact and publishes it to Forgejo generic packages. Uses the CV repo (forge.ops.eblu.me/eblume/cv) workflow as the reference implementation.
Prerequisites
- A Forgejo repo with a build pipeline (Dagger, script, etc.)
- The
FORGE_TOKENsecret provisioned via theforgejo_actions_secretsAnsible role
1. Add the repo to Ansible secrets
In ansible/roles/forgejo_actions_secrets/defaults/main.yml, add an entry under forgejo_actions_secrets_repos:
forgejo_actions_secrets_repos:
- repo: my-repo
secrets:
- name: FORGE_TOKEN
value_var: forgejo_api_token
Then provision: mise run provision-indri -- --tags forgejo_actions_secrets
This is required because Forgejo's built-in GITHUB_TOKEN does not have permissions for the packages API.
2. Create the workflow
Create .forgejo/workflows/<name>-release.yaml with workflow_dispatch and a version input. Use the semver bump pattern (see cv-release.yaml for the full upload flow, or build-blumeops.yaml for the version bump logic only — it uploads to Forgejo releases, not generic packages).
The upload step uses FORGE_TOKEN:
- name: Upload to Forgejo packages
env:
FORGE_TOKEN: ${{ secrets.FORGE_TOKEN }}
run: |
curl -fsSL \
-X PUT \
-H "Authorization: token $FORGE_TOKEN" \
--upload-file "./$TARBALL" \
"https://forge.ops.eblu.me/api/packages/eblume/generic/<package>/${VERSION}/${TARBALL}"
3. Link the package to the repo
After the first successful upload, the package appears under your user-level packages at https://forge.ops.eblu.me/eblume/-/packages but is not yet linked to the repo.
To link it:
- Go to
https://forge.ops.eblu.me/eblume/-/packages - Click the package name
- Click Settings
- Under Link this package to a repository, select the repo
- Click Save
Once linked, the package shows up in the repo's Packages tab and the repo links back to the package.
4. Create a deploy workflow (optional)
If the artifact is consumed by a k8s deployment, create a separate deploy workflow in blumeops (see cv-deploy.yaml). This keeps the build/release concern in the source repo and the deploy concern in blumeops.
Related
- deploy-k8s-service - Deploying the service that consumes the artifact
- add-ansible-role - Adding Ansible roles