Skip to content

docs: use full release tags in Docker commands - #220

Closed
Cassxbt wants to merge 1 commit into
circlefin:mainfrom
Cassxbt:docs/release-tag-consistency
Closed

Cassxbt wants to merge 1 commit into
circlefin:mainfrom
Cassxbt:docs/release-tag-consistency

Conversation

@Cassxbt

@Cassxbt Cassxbt commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Use the full release tag stored in ARC_VERSION when checking out a release, deriving Docker build metadata, and downloading the Compose configuration.

The version table exposes full tags such as v0.7.3. The current commands prepend another v, producing references such as vv0.7.3, which do not exist.

This complements #199, which updates the version table and arcup example.

Validation

  • Confirmed refs/tags/v0.7.3 exists; vv0.7.3 does not.
  • Confirmed the Compose URL for v0.7.3 returns HTTP 200; the doubled-prefix URL returns HTTP 404.
  • Shallow-cloned v0.7.3 and verified the corrected checkout and revision expressions.
  • Ran shell syntax validation and git diff --check.

No Docker image build or node bootstrap was run; those operations are not required to validate release-tag interpolation and would introduce unrelated compute and storage work.

@osr21

osr21 commented Jul 27, 2026

Copy link
Copy Markdown

Fix is correct and complete. A few verification notes:

Bug is real. The versions table uses v-prefixed tags (v0.6.0, v0.7.3), so ARC_VERSION is set with the prefix included. The four v$ARC_VERSION / v${ARC_VERSION} occurrences in the original all produce vv0.7.3-style strings that don't resolve to any tag, ref, or URL path. Confirmed on the base branch:

docs/installation.md:204:  git checkout v$ARC_VERSION
docs/installation.md:206:  git rev-parse v$ARC_VERSION^{commit}
docs/installation.md:207:  GIT_VERSION=v$ARC_VERSION
docs/installation.md:208:  git rev-parse --short v$ARC_VERSION^{commit}
docs/running-an-arc-node.md:287:  curl -O .../v${ARC_VERSION}/deployments/docker-compose.yml

No other files in the docs tree contain this pattern — the four changes in this PR are exhaustive.

^{commit} dereference is correct and necessary. v0.7.3 is an annotated tag (the API returns type: tag, not type: commit). The dereference was correct in the original; it's preserved and still correct after the fix.

Inner quoting in the rev-parse subshells is valid bash. $(...) resets the quoting context inside an outer double-quoted string, so "$(git rev-parse "${ARC_VERSION}^{commit}")" is parsed correctly — the inner "${ARC_VERSION}^{commit}" is a double-quoted string inside the command substitution, producing a single argument to git rev-parse. No word-splitting or glob expansion risk.

No conflict with the open PR #199 (different line ranges in installation.md, different content in running-an-arc-node.md).

LGTM.

@ZhiyuCircle

Copy link
Copy Markdown
Contributor

Hi @Cassxbt,

Thank you for your interest in contributing to Arc Node, and apologies for the delay in getting back to this PR.

We're closing out the pull request backlog that predates our current contribution policy. This PR is being closed because the number it references is a pull request, not an issue. All PRs must reference an existing issue using the format Closes: #XXX, and the author must be assigned to that issue before the PR is opened.

This is not a judgement on the change itself. If you'd still like to land it:

  1. Open an issue describing the problem, or find the existing one
  2. Comment on the issue requesting assignment, and wait for maintainer approval
  3. Open a fresh PR once you have been assigned

Please see CONTRIBUTING.md for details. Thanks again for taking the time to contribute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants