feat: add branch-based versioning for PR AMI builds

[jfroche]

Improvement of #1902 (reverted in #1905).

Manually create unique Postgres version names in branch often leads to version conflicts with the base branch versions. These conflicts force developers to deal with manual conflict resolution and unnecessary rebuilds.

To address this, this change implement automatic branch-based versioning for AMI builds triggered via workflow_dispatch on non-develop and non-release branches. The branch name is sanitized and appended to the Postgres version string.

We also publish pg_upgrade scripts and bin flake version right after the AMI release workflow completes.

Example: Branch 'multi-version-ext/pg-partman' produces postgres version 'multi-version-ext-pg-partman'

Summary by CodeRabbit

• New Features

  • Optional input to override Postgres version discovery when triggering release workflows.
  • Notices emitted on AMI publication and automatic triggering of downstream release workflows with the computed version.

• Chores

  • Reworked CI/CD to a two-stage AMI build, unified var generation and consistent version propagation.
  • Added self-hosted runner labels, explicit actions write permission, S3/catalog publishing, OIDC/cross-account role handling, and cleanup propagation improvements.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Restructures AMI release workflow into a two-stage Packer pipeline, centralizes generation/consumption of common-nix.vars.pkr.hcl, adds input-aware Postgres version branching in publishing workflows, introduces a runner lint config, and adds downstream workflow triggers and notifications.

Changes

Cohort / File(s)	Summary
Runner configuration .github/actionlint.yml	New GitHub Actions runner/lint configuration adding two self-hosted runner labels (blacksmith-2vcpu-ubuntu-2404-arm, blacksmith-4vcpu-ubuntu-2404).
AMI release workflow .github/workflows/ami-release-nix.yml	Reworks AMI pipeline into two Packer stages; sets EXECUTION_ID and POSTGRES_MAJOR_VERSION env vars; generates common-nix.vars.pkr.hcl; derives release version from that file; adds permissions: actions: write, Slack/notice emission, S3/catalog publishing, propagation of EXECUTION_ID to cleanup, and triggers for downstream workflows.
Publish/version workflows .github/workflows/publish-nix-pgupgrade-bin-flake-version.yml, .github/workflows/publish-nix-pgupgrade-scripts.yml	Add optional postgresVersion input handling: when provided, derive MAJOR_VERSION/VERSIONS and use the input as VERSION; otherwise fall back to existing ansible/vars.yml extraction (yq/jq). Remove nix-install-ephemeral step from scripts workflow and centralize input-priority version logic.

Sequence Diagram

sequenceDiagram
    participant GH as GitHub Actions
    participant Prep as Prepare Job
    participant PackerA as Packer Stage 1
    participant PackerB as Packer Stage 2
    participant S3 as S3/Catalog
    participant Notify as Slack/Notice
    participant Down as Downstream Workflows

    GH->>Prep: set EXECUTION_ID\nset POSTGRES_MAJOR_VERSION\n(optional) accept postgresVersion input
    Prep->>Prep: generate common-nix.vars.pkr.hcl
    Prep->>PackerA: init & build AMI (uses common-nix.vars.pkr.hcl, EXECUTION_ID)
    PackerA->>PackerB: handoff artifacts/metadata
    PackerB->>PackerB: init & build AMI (uses EXECUTION_ID, PG version)
    PackerB->>Prep: emit generated version (from common-nix.vars.pkr.hcl)
    Prep->>S3: publish artifacts & update catalog (include version)
    Prep->>Notify: send Slack/notice with published version
    Prep->>Down: trigger downstream workflows with computed version

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• feat: publish and use nix-catalog #1995: Modifies AMI release flow and S3/catalog publishing patterns similar to changes in ami-release-nix.yml.
• chore: bump version to correct new version for potential release #1991: Edits ansible/vars.yml Postgres version strings which are consumed by the updated version-extraction logic in these workflows.

Poem

🐰 Two-stage builds, I hop with glee,
Versions pulled or given to me,
I nibble HCL, stamp EXEC_ID,
Push artifacts, ring the feed,
CI carrots polished, shiny — whee! 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The description explains the problem, solution, and key implementation details, but lacks structured sections matching the template format which prompts users to select a sub-template.	Expand description by selecting an appropriate sub-template (Default or Extension Upgrade) from the template options and structure content accordingly.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: implementing automatic branch-based versioning for AMI builds triggered via workflow_dispatch.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In @.github/workflows/ami-release-nix.yml:
- Around line 214-227: The two GH CLI invocations in the steps named "Trigger
pg_upgrade_scripts workflow" and "Trigger pg_upgrade_bin flake version workflow"
omit an explicit ref so they may run on the repo default branch; update both gh
workflow run commands to include the current commit ref (e.g. add --ref "${{
github.sha }}" or --ref "${{ github.ref }}" to the command) so the downstream
workflows run on the same ref/commit as the AMI build.