Keep the Homebrew formula on the current release tarball - #2558
Merged
Conversation
|
SummaryCoverage spans normal package-version updates and release publication, validation of malformed inputs and authorization boundaries, and operational edge cases such as duplicate entries and overlapping releases. It also exercises whether the published package can actually build and install, revealing problems in both release integrity and downstream usability. Not safe to merge yet — a high-severity packaging failure makes the released package unusable, and additional medium-severity defects can publish mixed, malformed, or stale formula updates. These are all attributable to this PR and affect the release path rather than being isolated background observations. Tests run by Ito
Tip Reply with @itoqa to send us feedback on this test run. |
![itoqa[bot]](https://avatars.githubusercontent.com/in/2622614?s=60&v=4){kind=small}
| url = sys.argv[2] | ||
| sha256 = sys.argv[3] | ||
| text = path.read_text() | ||
| text, n_url = re.subn( |
There was a problem hiding this comment.
Duplicate formula leaves mixed versions
What failed: The updater exited with status 0 even though the fixture had two matching URLs. It rewrote the first URL and the checksum, left the second URL at version 0.50.2, and therefore did not meet the expected fail-closed behavior for duplicate matches.
Impact · Steps · Stub / mock · Analysis · Why this is likely a bug
- Severity: Medium
- Impact: Users installing the affected package may encounter a formula that points to two different releases, causing installation to fail or use the wrong release until the formula is corrected.
- Steps to Reproduce:
- Copy packaging/homebrew/doltlite.rb to a temporary formula file.
- Add a second copy of the canonical release URL to the temporary file.
- Run bump-formula.sh with version 9.9.9 and a valid 64-character lowercase checksum.
- Check the exit status and inspect every URL and checksum in the temporary file.
- Stub / mock content: The test used a temporary copy of the Homebrew formula with an extra URL entry and a synthetic lowercase checksum; no application mocks, route interception, or bypasses were used.
- Code Analysis: The PR-added implementation in packaging/homebrew/bump-formula.sh reads the entire formula at line 59, then calls re.subn for the URL at lines 60-65 with count=1 and for the checksum at lines 66-71 with count=1. With two matching URLs, n_url is still 1 because Python intentionally replaces only the first match; the same behavior applies independently to duplicate checksum entries. The guard at lines 72-75 checks only whether each replacement count is nonzero and equal to 1, so it cannot detect that additional matches remain. Because the first URL and checksum are held in the in-memory text and line 76 writes that text after the guard, a duplicate URL can be published alongside an unchanged old URL while the command returns success. The release workflow invokes this updater at .github/workflows/release.yml:1323 and then stages and pushes the formula at lines 1328-1330, so the partial rewrite is on the publication path. The smallest practical fix is to count all matches before writing and require exactly one URL and exactly one checksum, or to reject when either pattern has more than one match; retain the original file until both counts pass.
- Why this is likely a bug: This is not a runner-only symptom: the local reproduction produced exit_status=0 and showed a new 9.9.9 URL next to an unchanged 0.50.2 URL. The source explains the result exactly, because count=1 makes the match count mean replacements performed rather than total matches found, and write_text persists the incomplete result. Duplicate formula entries are an organic integrity failure that can arise from an accidental merge or manual edit, and the release job treats a zero exit status as safe to commit and push. Rejecting every count other than exactly one before writing is a targeted fix that preserves the normal single-entry update path.
Relevant code
packaging/homebrew/bump-formula.sh:60-75
text, n_url = re.subn(
r'url "https://github.com/dolthub/doltlite/releases/download/v[^"]+"',
f'url "{url}"',
text,
count=1,
)
text, n_sha = re.subn(
r'sha256 "[0-9a-fA-F]+"',
f'sha256 "{sha256}"',
text,
count=1,
)
if n_url != 1 or n_sha != 1:packaging/homebrew/bump-formula.sh:76-77
path.write_text(text).github/workflows/release.yml:1320-1330
gh release download "${VERSION}" --repo dolthub/doltlite \
+ --pattern "${asset}" --dir /tmp
sha256=$(sha256sum "/tmp/${asset}" | awk '{print $1}')
bash packaging/homebrew/bump-formula.sh "${version}" "${sha256}"
...
git add packaging/homebrew/doltlite.rb
git commit -m "Bump Homebrew formula to ${version}"
git push origin masterEvidence Package
Copy prompt for an agent
Ito QA identified the following failure during automated PR testing. Please investigate and propose a fix.
**Medium severity — Duplicate formula leaves mixed versions**
**What failed:** The updater exited with status 0 even though the fixture had two matching URLs. It rewrote the first URL and the checksum, left the second URL at version 0.50.2, and therefore did not meet the expected fail-closed behavior for duplicate matches.
- **Impact:** Users installing the affected package may encounter a formula that points to two different releases, causing installation to fail or use the wrong release until the formula is corrected.
- **Steps to reproduce:**
1. Copy packaging/homebrew/doltlite.rb to a temporary formula file.
2. Add a second copy of the canonical release URL to the temporary file.
3. Run bump-formula.sh with version 9.9.9 and a valid 64-character lowercase checksum.
4. Check the exit status and inspect every URL and checksum in the temporary file.
- **Stub / mock content:** The test used a temporary copy of the Homebrew formula with an extra URL entry and a synthetic lowercase checksum; no application mocks, route interception, or bypasses were used.
- **Code analysis:** The PR-added implementation in packaging/homebrew/bump-formula.sh reads the entire formula at line 59, then calls re.subn for the URL at lines 60-65 with count=1 and for the checksum at lines 66-71 with count=1. With two matching URLs, n_url is still 1 because Python intentionally replaces only the first match; the same behavior applies independently to duplicate checksum entries. The guard at lines 72-75 checks only whether each replacement count is nonzero and equal to 1, so it cannot detect that additional matches remain. Because the first URL and checksum are held in the in-memory text and line 76 writes that text after the guard, a duplicate URL can be published alongside an unchanged old URL while the command returns success. The release workflow invokes this updater at .github/workflows/release.yml:1323 and then stages and pushes the formula at lines 1328-1330, so the partial rewrite is on the publication path. The smallest practical fix is to count all matches before writing and require exactly one URL and exactly one checksum, or to reject when either pattern has more than one match; retain the original file until both counts pass.
- **Why this is likely a bug:** This is not a runner-only symptom: the local reproduction produced exit_status=0 and showed a new 9.9.9 URL next to an unchanged 0.50.2 URL. The source explains the result exactly, because count=1 makes the match count mean replacements performed rather than total matches found, and write_text persists the incomplete result. Duplicate formula entries are an organic integrity failure that can arise from an accidental merge or manual edit, and the release job treats a zero exit status as safe to commit and push. Rejecting every count other than exactly one before writing is a targeted fix that preserves the normal single-entry update path.
**Relevant code:**
`packaging/homebrew/bump-formula.sh:60-75`
~~~python
text, n_url = re.subn(
r'url "https://github.com/dolthub/doltlite/releases/download/v[^"]+"',
f'url "{url}"',
text,
count=1,
)
text, n_sha = re.subn(
r'sha256 "[0-9a-fA-F]+"',
f'sha256 "{sha256}"',
text,
count=1,
)
if n_url != 1 or n_sha != 1:
~~~
`packaging/homebrew/bump-formula.sh:76-77`
~~~python
path.write_text(text)
~~~
`.github/workflows/release.yml:1320-1330`
~~~yaml
gh release download "${VERSION}" --repo dolthub/doltlite \
+ --pattern "${asset}" --dir /tmp
sha256=$(sha256sum "/tmp/${asset}" | awk '{print $1}')
bash packaging/homebrew/bump-formula.sh "${version}" "${sha256}"
...
git add packaging/homebrew/doltlite.rb
git commit -m "Bump Homebrew formula to ${version}"
git push origin master
~~~
|
|
||
| uses_from_macos "zlib" | ||
|
|
||
| def install |
There was a problem hiding this comment.
Homebrew package cannot finish building
What failed: The package build stops before installing any of the expected tools or development files because the downloaded source archive does not contain one of its required build definition files.
Impact · Steps · Stub / mock · Analysis · Why this is likely a bug
- Severity: High
- Impact: Users who install the affected Homebrew package cannot install or use the DoltLite command-line tool, remote server, or development files. The package remains unusable until a release with the missing build file is published.
- Steps to Reproduce:
- Install the formula from packaging/homebrew/doltlite.rb using Homebrew.
- Let Homebrew download and extract the v0.50.2 doltlite-autoconf-0.50.2.tar.gz source archive.
- Run the formula build, which configures the source and requests doltlite, doltlite-remotesrv, and doltlite-lib.
- Observe that the build cannot complete and that the expected binaries, library, and header are not installed.
- Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
- Code Analysis: packaging/homebrew/doltlite.rb lines 21-35 runs ../configure and then invokes make for doltlite, doltlite-remotesrv, and doltlite-lib before installing the binaries, header, and libraries. main.mk lines 559-561 unconditionally executes
include $(TOP)/doltlite.mk, so a clean extracted source tree must contain doltlite.mk for configure-generated makefiles to work. The PR-added Package autoconf source step in .github/workflows/release.yml lines 96-104 uses an explicit tar command and includes main.mk, source directories, and other build inputs, but not doltlite.mk. The repository checkout has doltlite.mk, confirming the build dependency exists in source control, while the explicit release file list prevents it from entering the archive. The recorded formula information points at v0.50.2 and the recorded expected installation paths are absent, matching this source-level failure. The targeted remediation is to add doltlite.mk to the tar command's file list, then regenerate and validate the release archive with the formula build commands. - Why this is likely a bug: This is a deterministic artifact contract failure rather than a Homebrew or browser limitation. The formula explicitly requires a clean source build and the makefile explicitly requires doltlite.mk, but the PR's release packaging command excludes that file from the archive it publishes. Any user installing the formula from that archive receives the same incomplete source and cannot reach the documented binaries or C API smoke check. The failure is directly attributable to the changed file list, and adding the missing makefile is a narrow fix.
Relevant code
packaging/homebrew/doltlite.rb:21-35
def install
mkdir "build" do
system "../configure"
system "make", "doltlite", "doltlite-remotesrv", "doltlite-lib"
bin.install "doltlite", "doltlite-remotesrv"
include.install "sqlite3.h" => "doltlite.h"
lib.install "libdoltlite.a"
lib.install OS.mac? ? "libdoltlite.dylib" : "libdoltlite.so"
end
endmain.mk:559-561
# Prolly engine and version-control layer (see doltlite.mk).
#
include $(TOP)/doltlite.mk.github/workflows/release.yml:96-104
tar czf doltlite-autoconf-${VERSION}.tar.gz \
--transform "s,^,doltlite-autoconf-${VERSION}/," \
configure Makefile.in Makefile.linux-generic Makefile.msc main.mk \
auto.def VERSION manifest manifest.tags manifest.uuid \
pragma.h magic.txt lempar.c \
sqlite3.pc.in sqlite.pc.in \
src/ ext/ tool/ autosetup/ autoconf/ \
sqlite3.c sqlite3.h sqlite3ext.h sqlite3session.h \
.dolt_release_versiondoltlite.mk:1-7
#
# doltlite.mk -- prolly engine and version-control layer build definitions.
#
# Kept out of main.mk so upstream SQLite changes to main.mk merge without
# stepping on doltlite's additions. Included from main.mk at the point
# where these lines append to LIBOBJS0 and OPT_FEATURE_FLAGS, so ordering
# is identical to having them inline.Evidence Package
Copy prompt for an agent
Ito QA identified the following failure during automated PR testing. Please investigate and propose a fix.
**High severity — Homebrew package cannot finish building**
**What failed:** The package build stops before installing any of the expected tools or development files because the downloaded source archive does not contain one of its required build definition files.
- **Impact:** Users who install the affected Homebrew package cannot install or use the DoltLite command-line tool, remote server, or development files. The package remains unusable until a release with the missing build file is published.
- **Steps to reproduce:**
1. Install the formula from packaging/homebrew/doltlite.rb using Homebrew.
2. Let Homebrew download and extract the v0.50.2 doltlite-autoconf-0.50.2.tar.gz source archive.
3. Run the formula build, which configures the source and requests doltlite, doltlite-remotesrv, and doltlite-lib.
4. Observe that the build cannot complete and that the expected binaries, library, and header are not installed.
- **Stub / mock content:** No stubs, mocks, or bypasses were applied for this test in the recorded run.
- **Code analysis:** packaging/homebrew/doltlite.rb lines 21-35 runs ../configure and then invokes make for doltlite, doltlite-remotesrv, and doltlite-lib before installing the binaries, header, and libraries. main.mk lines 559-561 unconditionally executes `include $(TOP)/doltlite.mk`, so a clean extracted source tree must contain doltlite.mk for configure-generated makefiles to work. The PR-added Package autoconf source step in .github/workflows/release.yml lines 96-104 uses an explicit tar command and includes main.mk, source directories, and other build inputs, but not doltlite.mk. The repository checkout has doltlite.mk, confirming the build dependency exists in source control, while the explicit release file list prevents it from entering the archive. The recorded formula information points at v0.50.2 and the recorded expected installation paths are absent, matching this source-level failure. The targeted remediation is to add doltlite.mk to the tar command's file list, then regenerate and validate the release archive with the formula build commands.
- **Why this is likely a bug:** This is a deterministic artifact contract failure rather than a Homebrew or browser limitation. The formula explicitly requires a clean source build and the makefile explicitly requires doltlite.mk, but the PR's release packaging command excludes that file from the archive it publishes. Any user installing the formula from that archive receives the same incomplete source and cannot reach the documented binaries or C API smoke check. The failure is directly attributable to the changed file list, and adding the missing makefile is a narrow fix.
**Relevant code:**
`packaging/homebrew/doltlite.rb:21-35`
~~~ruby
def install
mkdir "build" do
system "../configure"
system "make", "doltlite", "doltlite-remotesrv", "doltlite-lib"
bin.install "doltlite", "doltlite-remotesrv"
include.install "sqlite3.h" => "doltlite.h"
lib.install "libdoltlite.a"
lib.install OS.mac? ? "libdoltlite.dylib" : "libdoltlite.so"
end
end
~~~
`main.mk:559-561`
~~~make
# Prolly engine and version-control layer (see doltlite.mk).
#
include $(TOP)/doltlite.mk
~~~
`.github/workflows/release.yml:96-104`
~~~yaml
tar czf doltlite-autoconf-${VERSION}.tar.gz \
--transform "s,^,doltlite-autoconf-${VERSION}/," \
configure Makefile.in Makefile.linux-generic Makefile.msc main.mk \
auto.def VERSION manifest manifest.tags manifest.uuid \
pragma.h magic.txt lempar.c \
sqlite3.pc.in sqlite.pc.in \
src/ ext/ tool/ autosetup/ autoconf/ \
sqlite3.c sqlite3.h sqlite3ext.h sqlite3session.h \
.dolt_release_version
~~~
`doltlite.mk:1-7`
~~~make
#
# doltlite.mk -- prolly engine and version-control layer build definitions.
#
# Kept out of main.mk so upstream SQLite changes to main.mk merge without
# stepping on doltlite's additions. Included from main.mk at the point
# where these lines append to LIBOBJS0 and OPT_FEATURE_FLAGS, so ordering
# is identical to having them inline.
~~~
| # homebrew-core accepts a submission. Pinning a stale tarball ships a | ||
| # pre-format-freeze engine. After the autoconf tarball is on the GitHub | ||
| # release, rewrite url/sha256 and push to master. | ||
| release-homebrew: |
There was a problem hiding this comment.
Concurrent releases can miss formula updates
What failed: When two releases update the formula at the same time, one update can be rejected or missing from the final branch.
Impact · Steps · Stub / mock · Analysis · Why this is likely a bug
- Severity: Medium
- Impact: When two releases run at the same time, one release may be missing or the package formula may stay stale. Users may not see the newest release until an operator checks the branch and reruns the release job.
- Steps to Reproduce:
- Start two tagged releases close together so both formula-update jobs run at the same time.
- Let both jobs check out the master branch, calculate their version and checksum changes, and create commits.
- Let both jobs push their commits to master.
- Check the job results and confirm that one push can be rejected as non-fast-forward or that the final formula does not contain both updates.
- Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
- Code Analysis: The PR diff adds .github/workflows/release.yml lines 1288-1330 as the release-homebrew job. The job checks out ref master at lines 1310-1313, downloads the release asset and rewrites the formula at lines 1315-1323, then stages and commits the result at lines 1328-1329 and executes git push origin master at line 1330. The added job has no job-level concurrency group, and the workflow has no pull/rebase or retry between checkout and push. Two overlapping runs can therefore start from the same master commit; after the first push advances master, the second direct push is non-fast-forward and exits because set -e is enabled. If a later process retries from an older checkout or otherwise publishes its stale commit, it can also overwrite the other release's formula update. The smallest practical fix is to serialize this job with a concurrency group for master formula publication, or fetch and rebase master immediately before pushing with bounded retry and explicit conflict failure.
- Why this is likely a bug: The formula is described as the source of truth for the package, so every completed release is expected to publish its matching version and checksum. The new job writes to the shared master branch from an earlier checkout but does not coordinate concurrent writers or recover from a branch update. This creates a deterministic race in a release-critical path, with a direct workaround of rerunning the failed job only after confirming which release update is already present.
Relevant code
.github/workflows/release.yml:1288-1313
release-homebrew:
needs: release
runs-on: ubuntu-latest
...
- uses: actions/checkout@v4
with:
ref: master
token: ${{ secrets.RELEASE_BOT_TOKEN }}.github/workflows/release.yml:1323-1330
bash packaging/homebrew/bump-formula.sh "${version}" "${sha256}"
git add packaging/homebrew/doltlite.rb
git commit -m "Bump Homebrew formula to ${version}"
git push origin masterEvidence Package
Copy prompt for an agent
Ito QA identified the following failure during automated PR testing. Please investigate and propose a fix.
**Medium severity — Concurrent releases can miss formula updates**
**What failed:** When two releases update the formula at the same time, one update can be rejected or missing from the final branch.
- **Impact:** When two releases run at the same time, one release may be missing or the package formula may stay stale. Users may not see the newest release until an operator checks the branch and reruns the release job.
- **Steps to reproduce:**
1. Start two tagged releases close together so both formula-update jobs run at the same time.
2. Let both jobs check out the master branch, calculate their version and checksum changes, and create commits.
3. Let both jobs push their commits to master.
4. Check the job results and confirm that one push can be rejected as non-fast-forward or that the final formula does not contain both updates.
- **Stub / mock content:** No stubs, mocks, or bypasses were applied for this test in the recorded run.
- **Code analysis:** The PR diff adds .github/workflows/release.yml lines 1288-1330 as the release-homebrew job. The job checks out ref master at lines 1310-1313, downloads the release asset and rewrites the formula at lines 1315-1323, then stages and commits the result at lines 1328-1329 and executes git push origin master at line 1330. The added job has no job-level concurrency group, and the workflow has no pull/rebase or retry between checkout and push. Two overlapping runs can therefore start from the same master commit; after the first push advances master, the second direct push is non-fast-forward and exits because set -e is enabled. If a later process retries from an older checkout or otherwise publishes its stale commit, it can also overwrite the other release's formula update. The smallest practical fix is to serialize this job with a concurrency group for master formula publication, or fetch and rebase master immediately before pushing with bounded retry and explicit conflict failure.
- **Why this is likely a bug:** The formula is described as the source of truth for the package, so every completed release is expected to publish its matching version and checksum. The new job writes to the shared master branch from an earlier checkout but does not coordinate concurrent writers or recover from a branch update. This creates a deterministic race in a release-critical path, with a direct workaround of rerunning the failed job only after confirming which release update is already present.
**Relevant code:**
`.github/workflows/release.yml:1288-1313`
~~~yaml
release-homebrew:
needs: release
runs-on: ubuntu-latest
...
- uses: actions/checkout@v4
with:
ref: master
token: ${{ secrets.RELEASE_BOT_TOKEN }}
~~~
`.github/workflows/release.yml:1323-1330`
~~~yaml
bash packaging/homebrew/bump-formula.sh "${version}" "${sha256}"
git add packaging/homebrew/doltlite.rb
git commit -m "Bump Homebrew formula to ${version}"
git push origin master
~~~
| esac | ||
| done | ||
|
|
||
| VERSION="${1:-}" |
There was a problem hiding this comment.
Malformed versions rewrite formula files
What failed: The helper returned success for a path-like version and changed the formula. It wrote a URL containing path traversal segments, although malformed versions should fail and leave the file unchanged.
Impact · Steps · Stub / mock · Analysis · Why this is likely a bug
- Severity: Medium
- Impact: A malformed release version can be accepted as successful and leave the Homebrew formula pointing to an invalid download URL. Users may be unable to install or upgrade that release until the formula is corrected.
- Steps to Reproduce:
- Copy the Homebrew formula to a temporary file and record its original contents.
- Run the release helper against that copy with version 9.9/../../evil and a valid 64-character checksum.
- Check the exit status, compare the file with its original contents, and inspect the new download URL.
- Repeat with a valid version such as 1.2.3 to confirm the normal path still produces matching URL components.
- Stub / mock content: The check used a temporary copy of the Homebrew formula and a synthetic valid checksum; no network, authentication, or production release was used.
- Code Analysis: The production defect is in packaging/homebrew/bump-formula.sh, which this PR adds. Lines 28-33 only check whether VERSION is non-empty; line 34 removes one leading v, but there is no semantic-version or character validation. Lines 36-39 validate SHA256 only. Line 49 then interpolates VERSION twice into the GitHub release path and archive name, so input such as 9.9/../../evil becomes an invalid URL. The recorded reproduction returned status 0, changed the copied formula bytes, and produced https://github.com/dolthub/doltlite/releases/download/v9.9/../../evil/doltlite-autoconf-9.9/../../evil.tar.gz. The smallest fix is to validate VERSION against the accepted release-version format immediately after the optional v is removed and before constructing URL, returning nonzero before the Python rewrite for invalid input.
- Why this is likely a bug: This is not a browser or fixture-only problem: the helper's source path deterministically accepts any non-empty VERSION and constructs the release URL from it. The same code is called by the new release-homebrew job in .github/workflows/release.yml, so a malformed tag or operator input can turn the checked-in source-of-truth formula into an unusable one while reporting success. The valid 1.2.3 case works, which isolates the defect to missing rejection of malformed versions rather than the general rewrite logic. Adding a focused version check before line 49 preserves the intended valid-version behavior and prevents mutation on invalid input.
Relevant code
packaging/homebrew/bump-formula.sh:28-39
VERSION="${1:-}"
SHA256="${2:-}"
if [ -z "$VERSION" ] || [ -z "$SHA256" ]; then
echo "usage: bump-formula.sh [--file PATH] VERSION SHA256" >&2
exit 2
fi
VERSION="${VERSION#v}"
if ! printf '%s' "$SHA256" | grep -Eq '^[0-9a-f]{64}$'; thenpackaging/homebrew/bump-formula.sh:41-49
if [ -z "$FORMULA" ]; then
FORMULA="$(cd "$(dirname "$0")" && pwd)/doltlite.rb"
fi
if [ ! -f "$FORMULA" ]; then
echo "formula not found: $FORMULA" >&2
exit 1
fi
URL="https://github.com/dolthub/doltlite/releases/download/v${VERSION}/doltlite-autoconf-${VERSION}.tar.gz"Evidence Package
Copy prompt for an agent
Ito QA identified the following failure during automated PR testing. Please investigate and propose a fix.
**Medium severity — Malformed versions rewrite formula files**
**What failed:** The helper returned success for a path-like version and changed the formula. It wrote a URL containing path traversal segments, although malformed versions should fail and leave the file unchanged.
- **Impact:** A malformed release version can be accepted as successful and leave the Homebrew formula pointing to an invalid download URL. Users may be unable to install or upgrade that release until the formula is corrected.
- **Steps to reproduce:**
1. Copy the Homebrew formula to a temporary file and record its original contents.
2. Run the release helper against that copy with version 9.9/../../evil and a valid 64-character checksum.
3. Check the exit status, compare the file with its original contents, and inspect the new download URL.
4. Repeat with a valid version such as 1.2.3 to confirm the normal path still produces matching URL components.
- **Stub / mock content:** The check used a temporary copy of the Homebrew formula and a synthetic valid checksum; no network, authentication, or production release was used.
- **Code analysis:** The production defect is in packaging/homebrew/bump-formula.sh, which this PR adds. Lines 28-33 only check whether VERSION is non-empty; line 34 removes one leading v, but there is no semantic-version or character validation. Lines 36-39 validate SHA256 only. Line 49 then interpolates VERSION twice into the GitHub release path and archive name, so input such as 9.9/../../evil becomes an invalid URL. The recorded reproduction returned status 0, changed the copied formula bytes, and produced https://github.com/dolthub/doltlite/releases/download/v9.9/../../evil/doltlite-autoconf-9.9/../../evil.tar.gz. The smallest fix is to validate VERSION against the accepted release-version format immediately after the optional v is removed and before constructing URL, returning nonzero before the Python rewrite for invalid input.
- **Why this is likely a bug:** This is not a browser or fixture-only problem: the helper's source path deterministically accepts any non-empty VERSION and constructs the release URL from it. The same code is called by the new release-homebrew job in .github/workflows/release.yml, so a malformed tag or operator input can turn the checked-in source-of-truth formula into an unusable one while reporting success. The valid 1.2.3 case works, which isolates the defect to missing rejection of malformed versions rather than the general rewrite logic. Adding a focused version check before line 49 preserves the intended valid-version behavior and prevents mutation on invalid input.
**Relevant code:**
`packaging/homebrew/bump-formula.sh:28-39`
~~~bash
VERSION="${1:-}"
SHA256="${2:-}"
if [ -z "$VERSION" ] || [ -z "$SHA256" ]; then
echo "usage: bump-formula.sh [--file PATH] VERSION SHA256" >&2
exit 2
fi
VERSION="${VERSION#v}"
if ! printf '%s' "$SHA256" | grep -Eq '^[0-9a-f]{64}$'; then
~~~
`packaging/homebrew/bump-formula.sh:41-49`
~~~bash
if [ -z "$FORMULA" ]; then
FORMULA="$(cd "$(dirname "$0")" && pwd)/doltlite.rb"
fi
if [ ! -f "$FORMULA" ]; then
echo "formula not found: $FORMULA" >&2
exit 1
fi
URL="https://github.com/dolthub/doltlite/releases/download/v${VERSION}/doltlite-autoconf-${VERSION}.tar.gz"
~~~
Contributor
DoltLite performance vs PR base
blobpk details
compositepk details
int details
textpk details
vc details
All relative performance gates passed. |
Contributor
DoltLite source coverage
Merged 203 pooled raw profiles from the distributed Linux correctness jobs. Per-file coverage (98 files)
|
packaging/homebrew/doltlite.rb pinned v0.10.6, a pre-format-freeze engine. Homebrew-core will not take the formula yet, but the in-repo copy is the source of truth and must not ship a stale pin. Point url/sha256 at v0.50.2. packaging/homebrew/bump-formula.sh rewrites those fields; the release-homebrew job runs it after the autoconf tarball is uploaded and pushes the bump to master. Fixes #2542 Co-Authored-By: Grok 4.6 <noreply@x.ai>
Ito QA: the autoconf tarball omitted doltlite.mk, so main.mk could not build doltlite from the formula's source URL. Include it and grep the archive after packing. bump-formula.sh now requires X.Y.Z, counts url/sha256 matches before writing, and leaves the file alone on a reject. The release job serializes on a concurrency group and retries fetch/reset/push so overlapping tags do not clobber a newer formula. Co-Authored-By: Grok 4.6 <noreply@x.ai>
timsehn
force-pushed
the
fix/2542-homebrew-formula-bump
branch
from
September 2, 2026 01:24
2877cca to
a4634d2
Compare
Collaborator
Author
|
Addressed the Ito QA failures in a4634d2:
|
Commit: SummaryCoverage spans release packaging and publishing, formula updates, retry and concurrency handling, credential and input validation, repeat-delivery safety, and clean archive builds. It includes normal release flows plus malformed-input, failure-recovery, race-condition, and Linux shared-library integration checks, with the change-related behavior otherwise healthy. Safe to merge — the only failure is a medium-severity Linux packaging defect that is explicitly unrelated to this PR, while the PR’s release, formula, validation, and retry behaviors show no regressions or new failures. The Linux embedding issue is a flag for later rather than a merge blocker. Tests run by Ito
Additional Findings DetailsThese findings are unrelated to the current changes but were observed during testing. 🟡 Linux embedding program cannot start
Evidence PackageTip Reply with @itoqa to send us feedback on this test run. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2542.
packaging/homebrew/doltlite.rbpinnedv0.10.6, which predates the beta format freeze. Homebrew-core will not accept the formula until notability, but this in-repo copy is the source of truth and was shipping a stale engine to anyone who used it.The formula now points at the
v0.50.2autoconf tarball.packaging/homebrew/bump-formula.shrewritesurl/sha256. Arelease-homebrewjob runs after the GitHub release has the tarball, hashes it, and pushes the bump tomaster.test/homebrew_formula_test.shrejects av0.10.6pin, checks url/tarball versions agree, and exercises the bump script.Co-Authored-By: Grok 4.6 noreply@x.ai