Skip to content

Bump tools pin to v0.8.39 in release workflows - #1224

Open
ibrahim halatci (ihalatci) wants to merge 1 commit into
all-citusfrom
ihalatci-bump-tools-pin-v0839
Open

Bump tools pin to v0.8.39 in release workflows#1224
ibrahim halatci (ihalatci) wants to merge 1 commit into
all-citusfrom
ihalatci-bump-tools-pin-v0839

Conversation

@ihalatci

Copy link
Copy Markdown
Contributor

What

Bumps the citusdata/tools pin from v0.8.36 to v0.8.39 in the two
release workflows that were left behind:

Workflow Before After
build-package.yml v0.8.36 v0.8.39
update_package_properties.yml v0.8.36 v0.8.39
build-citus-community-nightlies.yml v0.8.39 unchanged

Diff is exactly +2/-2 (one line per file). All three all-citus
workflows now agree on v0.8.39.

Why

v0.8.36 carries a bug in citus_package.py::get_postgres_versions()
the nightly exclusion filter iterated release_versions instead of
nightly_versions, so the nightly list was rebuilt from the
already-release-filtered list:

if exclude_dict_nightly and platform_key_nightly in exclude_dict_nightly:
    nightly_versions = [
        v
        for v in release_versions      # <-- should be nightly_versions
        if v not in exclude_dict_nightly[platform_key_nightly]
    ]

Fixed in v0.8.39 (tools #423).

This was dormant while pg_exclude.yml had nightly: {} — an empty dict
is falsy, so the block never executed. It became reachable on this branch
once pg_exclude.yml gained a non-empty nightly: section:

exclude:
  nightly:
    all: [19]

all-citus is the only branch carrying a pg_exclude.yml, so it is the
only branch where this bug is reachable. develop, debian-hll and
debian-topn have no exclusion file and are intentionally untouched here.

Nothing is broken today, because the workflow that actually consumes
nightly versions (build-citus-community-nightlies.yml) was already
pinned to v0.8.39. This closes the gap so correctness no longer depends
on which workflow happens to run.

Upgrade risk

v0.8.36...v0.8.39 is 7 commits. Restricted to the scripts these two
workflows invoke, every change is additive:

  • citus_package.py — adds the ubuntu,resolute platform mapping, fixes
    the nightly filter above, and includes build stdout+stderr in the
    failure exception instead of stderr alone
  • upload_to_package_cloud.py — adds the ubuntu/resolute distro id
  • common_tool_methods.py — adds resolute to the ubuntu release list

update_package_properties.py is unchanged between the two tags.

The Docker-template changes in that range (including the removed
postgres-14 / postgres-15 templates) are driven by update_docker.py
and publish_docker.py, neither of which is invoked by these workflows.

Validation

  • Both files re-parsed with yaml.safe_load; job keys unchanged
    (build_package, trigger_package_tests, update_package_properties)
  • Committed blobs verified LF-only, and the existing double space after
    --depth=1 is preserved byte-for-byte
  • git diff --stat confirms 2 files changed, 2 insertions, 2 deletions

Conflicts

No overlap with #1220, which edits the arm64 debsigner build context at
line 98 of the same file. This PR touches line 64. The two merge cleanly
in either order.

build-package.yml and update_package_properties.yml still cloned tools
v0.8.36, while build-citus-community-nightlies.yml was already on
v0.8.39. Align all three.

v0.8.36 has a bug in citus_package.py get_postgres_versions(): the
nightly exclusion filter iterated release_versions instead of
nightly_versions, so nightly versions were rebuilt from the
already-release-filtered list. This became reachable once pg_exclude.yml
gained a non-empty nightly block (nightly: all: [19]) - previously
nightly: {} was falsy and the block never ran.

Between v0.8.36 and v0.8.39 the scripts these two workflows invoke
change only additively:
  - citus_package.py: adds ubuntu,resolute mapping; fixes the nightly
    filter; includes build stdout+stderr in the failure exception
  - upload_to_package_cloud.py: adds ubuntu/resolute distro id
  - common_tool_methods.py: adds resolute to the ubuntu release list
update_package_properties.py itself is unchanged between the two tags.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1ed7b58a-0ba9-4f47-a1de-3ee665bae7f2
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