[
https://issues.apache.org/jira/browse/THRIFT-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-6301.
--------------------------------
Fix Version/s: 0.26.0
Assignee: Jens Geyer
Resolution: Fixed
> veralign.sh rewrites third-party versions in lockfiles when they match the
> old Thrift version
> ---------------------------------------------------------------------------------------------
>
> Key: THRIFT-6301
> URL: https://issues.apache.org/jira/browse/THRIFT-6301
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
> Reporter: Jens Geyer
> Assignee: Jens Geyer
> Priority: Major
> Fix For: 0.26.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{build/veralign.sh}} updates the two Ruby {{Gemfile.lock}} files and the
> three npm {{package-lock.json}} files with {{simpleReplace}}, which is a
> {{sed "s/<old>/<new>/g"}} over the whole file. A lockfile lists every
> dependency with its version, so any third-party package that happens to be
> locked at the old Thrift version gets rewritten as well.
> h3. It already broke master
> The bump to 0.26.0 (451efc7a7) turned {{bake (0.25.0)}} in
> {{test/rb/Gemfile.lock}} into {{bake (0.26.0)}}. bake has no 0.26.0 release,
> so {{bundle install}} in {{test/rb}} fails. That runs in the setup step of
> all 24 {{cross-test}} jobs, and all of them fail:
> {noformat}
> Your bundle is locked to bake (0.26.0) from rubygems repository
> https://rubygems.org/ or installed locally, but that version can no longer be
> found in that source.
> {noformat}
> [PR #3884|https://github.com/apache/thrift/pull/3884] repairs the lockfile
> itself. This ticket is about the tool.
> h3. The next bump would do it again, without failing
> {{test/rb/Gemfile.lock}} also locks {{protocol-http2 (0.26.0)}}, a real
> release that came in with THRIFT-6079. Bumping 0.26.0 to 0.27.0 would rewrite
> it to {{protocol-http2 (0.27.0)}}. That version exists too, so nothing would
> fail; the lockfile would just name a version bundler never resolved.
> h3. The npm lockfiles are exposed the same way
> Each {{package-lock.json}} is listed twice in {{FILES}}, first with
> {{jsonReplace}} and then with {{simpleReplace}}. {{FILES}} is an associative
> array, so the second assignment replaces the first and only {{simpleReplace}}
> runs. None of the npm dependencies happened to be locked at 0.25.0 this time.
> h3. Proposed fix
> * {{gemlockReplace}} replaces only the {{thrift (<old>)}} spec line of a
> {{Gemfile.lock}}.
> * {{npmlockReplace}} sets only the root package's {{version}} and
> {{packages\[""].version}}, through jq. For all three files jq reproduces
> npm's formatting byte for byte.
> * {{escapeVersion}} learns to escape parentheses, since {{replace()}} hands
> the same pattern to {{grep -E}} and to a basic-regex {{sed}}.
> _Drafted with AI assistance (Claude Opus 5); reviewed and filed by Jens
> Geyer._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
