Skip to content

ci(docker): publish only from main and releases; latest follows main - #988

Merged
giswqs merged 2 commits into
mainfrom
ci/docker-publish-main
Oct 27, 2026
Merged

giswqs merged 2 commits into
mainfrom
ci/docker-publish-main

Conversation

@giswqs

@giswqs giswqs commented Oct 26, 2026 •

Copy link
Copy Markdown
Member

Follow-up to #986 (it auto-merged before these landed).

  • latest now follows main, as edge does. Before, only a release published it, and since v0.4.0 predates the Dockerfile, a plain docker run ghcr.io/opengeos/rustgis (or rustgis-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.
  • A manual run (workflow_dispatch) on a feature branch pushed that branch's sha-<commit> tag to the public packages. Publishing is now gated on main or a release, through a workflow-level PUBLISH value that the publish steps check (cli-manifest repeats the condition in its job if, where env isn't available). Anywhere else the run builds and smoke-tests only, as a pull request does.
  • Rewraps the GEOLIBRE_PARITY.md entry at 100 columns.

Summary by CodeRabbit

  • Documentation
    • Clarified that latest and edge images track builds from the main branch, while versioned tags identify releases.
    • Updated Docker self-hosting guidance for the CLI image and runtime configuration.
  • Build and Publishing
    • Manual runs on non-main branches build and smoke-test images without publishing. Publishing is limited to releases and builds from main.

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.
@coderabbitai

coderabbitai Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

No actionable comments were generated in the recent review.

Recent review info
Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: ASSERTIVE
  • Plan: Advanced
  • Run ID: 5d04e8e7-1b39-4030-b28b-89d51641c6a4
Commits

Reviewing files that changed from the base of the PR and between a01660e and 2cc109c.

Files selected for processing: 2
  • .github/workflows/docker.yml
  • docs/installation.md

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 4 remain after this review.

Walkthrough

The Docker workflow now gates publishing actions to release events and pushes to main. Manual runs on other branches build and smoke-test both images without publishing. The documentation describes the tag rules and clarifies the CLI image’s use and runtime settings.

Changes: Docker publishing

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: Normal

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: Passed 5
Check name Status Explanation
Title check Passed The title clearly summarizes the main Docker CI change: publishing only from main and releases, with latest following main.
Description check Passed 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 …
Docstring Coverage Passed 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 …
Linked Issues check Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check Passed Check skipped because no linked issues were found for this pull request.
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.

❤️ Share

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.

@github-actions

Copy link
Copy Markdown
Contributor

Code review

Checked the gating logic against GitHub's event semantics and every publish step in docker.yml, the docs and other workflows for stale publish claims, and the GEOLIBRE_PARITY.md rewrap for the 100-column rule. I found no bugs and no security issues. No inline comments were posted because the only finding is a documented nit.

Bugs: None found. PUBLISH resolves to the string "true"/"false", so env.PUBLISH == 'true' is correct. Traced cases:

  • push to main and workflow_dispatch on main publish.
  • release publishes, and github.ref is ignored for that event.
  • pull_request and workflow_dispatch on other branches build and smoke-test only.
  • cli-manifest runs only on release or main, so it never runs on a PR and never fails on missing digests.
  • All six publish-related steps (two logins, two publishes, digest record and upload) are gated. None were missed.

Security: None found. Login and push are skipped everywhere except main and releases. The packages: write job permission is unchanged, and fork PRs get no secrets.

Performance: None found.

Quality (nit, confidence high, no action required): The cli-manifest job if at .github/workflows/docker.yml:258 repeats the PUBLISH expression because job-level if cannot read env. The comment at lines 55–56 documents this, so the two must be kept in sync by hand. This is acceptable as written.

AGENTS.md: Compliant. Workflow-only change with no code. The GEOLIBRE_PARITY.md rewrap is under 100 columns. release-dry-run.yml dispatches only release.yml, and no docs describe the old branch-publish behavior.

Confidence: High that the change is correct as written.

Change size

Compared: the whole PR against main (merge base 1751941 to PR head a01660e).

Measure Value
Files changed 2 (added 0, modified 2, removed 0, renamed 0)
Size before 35.0 KB
Size after 35.2 KB
Total size change +256 B
Path Before After Change
.github/workflows/docker.yml 11.0 KB 11.3 KB +256 B
GEOLIBRE_PARITY.md 23.9 KB 23.9 KB 0 B

@github-actions

github-actions Bot commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

📖 Docs preview

Item Value
Preview https://preview.rustgis.app/pr-988/
Web app https://preview.rustgis.app/pr-988/app/
Commit 2cc109c

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.
@giswqs giswqs changed the title ci(docker): publish only from main and from releases ci(docker): publish only from main and releases; latest follows main Oct 27, 2026
Comment thread .github/workflows/docker.yml
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')

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@github-actions

Copy link
Copy Markdown
Contributor

Code review

Bugs: None found. The publish gate is consistent across all the publish steps. PUBLISH evaluates to the strings "true"/"false", so env.PUBLISH == 'true' is correct. Release events carry a tag ref, so they are covered by the event_name branch. Pull requests and manual runs on other branches get no push, sign-in or digest upload. The latest tag is gated on refs/heads/main as intended. I found no other latest references in the repo that are now stale.

Security: None found. github.ref and event_name go into if: and env:, not into shell run: scripts, so no injection path is opened. Permissions are unchanged.

Performance: None found. The change only adds conditions.

Quality:

  • latest now tracks main (confidence: high that it is a behaviour change; medium that it is unwanted). An untagged pull gets an unreleased build, where it previously got the newest stable release. The PR and docs/installation.md state this as intended. Please confirm the maintainers want it. Inline comment
  • The publish rule is duplicated (confidence: medium). The PUBLISH env value and the cli-manifest job if must be kept in sync by hand. A gate job with a publish output would give one source of truth, and could go in a follow-up. Inline comment

AGENTS.md: The docs were updated with the workflow change (docs/installation.md). The GEOLIBRE_PARITY.md rewrap is within 100 columns; the rewrapped entry measures 99. No code, wasm or layering rules apply to these files.

Change size

Compared with the base branch: the whole PR against main (merge base 1751941 to PR head 2cc109c).

Measure Value
Files changed 3 (0 added, 3 modified, 0 removed, 0 renamed)
Size before 52.8 KB
Size after 52.9 KB
Total size change +209 B
Path Before After Change
.github/workflows/docker.yml 11.0 KB 11.2 KB +212 B
docs/installation.md 17.8 KB 17.8 KB -3 B
GEOLIBRE_PARITY.md 23.9 KB 23.9 KB 0 B

@giswqs
giswqs merged commit 4fb510c into main Oct 27, 2026
15 checks passed
@giswqs
giswqs deleted the ci/docker-publish-main branch October 27, 2026 00:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant