Repository navigation
ci(docker): publish only from main and releases; latest follows main - #988
Conversation
A manual run of the Docker images workflow on a feature branch pushed that branch's sha tag to the public ghcr.io packages. Publishing is now gated on main or a release; elsewhere the run builds and smoke-tests only, as a pull request does. Also rewraps the GEOLIBRE_PARITY.md entry on the images at 100 columns.
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Publishing policy and image tags .github/workflows/docker.yml, docs/installation.md |
The workflow defines PUBLISH for release events and pushes to main, and assigns latest to builds from main. The installation documentation describes latest and edge as main builds, and version tags as releases. |
Image publishing gates .github/workflows/docker.yml, GEOLIBRE_PARITY.md |
Web and CLI registry login and publishing actions, CLI digest recording and upload, and the CLI manifest job run only under the specified publish conditions. The parity entry describes the CLI image and its runtime settings. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Possibly related PRs
- opengeos/RustGIS#986: Adds the Docker workflow that this change updates with publishing conditions.
Merge Risk: 
Minimal · up to 2cc10
-
No actionable merge-blocking risk remains.
Pre-merge checks: 
5
-
Full details: Description check
-
Explanation
The description clearly explains the publishing changes, tag behavior, branch conditions, and related issue. It does not include the template's Testing heading or test results, but the description is otherwise complete and relevant.
Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks the tags at dawn,main gets latest as builds roll on.
Release tags keep their numbered place,
While branch runs test at their own pace.
No publish step begins unless gates say so.
Comment @coderabbitai help to get the list of available commands.
Code reviewChecked the gating logic against GitHub's event semantics and every publish step in Bugs: None found.
Security: None found. Login and push are skipped everywhere except Performance: None found. Quality (nit, confidence high, no action required): The AGENTS.md: Compliant. Workflow-only change with no code. The Confidence: High that the change is correct as written. Change sizeCompared: the whole PR against main (merge base 1751941 to PR head a01660e).
|
📖 Docs preview
GitHub Pages takes a minute or two to publish a new commit. |
`latest` was published only by a release, so until the first release with images a plain `docker run ghcr.io/opengeos/rustgis` found no image. It now moves with every update to main, as edge does; releases keep their <version> and <major>.<minor> tags.
| name: Command line image (publish) | ||
| needs: cli | ||
| if: github.repository == 'opengeos/RustGIS' && github.event_name != 'pull_request' | ||
| if: github.repository == 'opengeos/RustGIS' && (github.event_name == 'release' || github.ref == 'refs/heads/main') |
There was a problem hiding this comment.
Quality (confidence: medium). The publish rule is now written twice: the PUBLISH env value (line 56) and this job-level if. The comment at line 55 notes the duplication, but nothing enforces that they stay equal, so a later edit to one could leave cli-manifest running while the cli job skips publishing, or the reverse. A small first job that computes publish as an output, with cli and cli-manifest both reading needs.<job>.outputs.publish, would keep one source of truth. It is a larger change than the rest of this PR, so it can go in a follow-up.
There was a problem hiding this comment.
Leaving this open as a marginal follow-up. The two conditions sit a few lines apart and the comment points from one to the other. A setup job just to emit one output would add a runner start to every run, which isn't worth it for a one-line rule.
Code reviewBugs: None found. The publish gate is consistent across all the publish steps. Security: None found. Performance: None found. The change only adds conditions. Quality:
AGENTS.md: The docs were updated with the workflow change ( Change sizeCompared with the base branch: the whole PR against main (merge base 1751941 to PR head 2cc109c).
|
Follow-up to #986 (it auto-merged before these landed).
latestnow followsmain, asedgedoes. Before, only a release published it, and since v0.4.0 predates the Dockerfile, a plaindocker run ghcr.io/opengeos/rustgis(orrustgis-cli) found no image until v0.5.0. Releases keep their<version>and<major>.<minor>tags. The docs and the workflow header describe the new tags.workflow_dispatch) on a feature branch pushed that branch'ssha-<commit>tag to the public packages. Publishing is now gated onmainor a release, through a workflow-levelPUBLISHvalue that the publish steps check (cli-manifestrepeats the condition in its jobif, whereenvisn't available). Anywhere else the run builds and smoke-tests only, as a pull request does.GEOLIBRE_PARITY.mdentry at 100 columns.Summary by CodeRabbit
latestandedgeimages track builds from themainbranch, while versioned tags identify releases.main.