feat: version per upstream release - #26
Merged
Merged
Conversation
Dom asked for the Tero layer version to match the DataDog version it is built from. An AWS layer version is a single integer that AWS only appends to, so it cannot be set to 119, and it has no room for a patch component. The previous workflow forced alignment by publishing filler versions in a loop until the counter reached the target. Put the upstream version in the layer name instead: Tero-Datadog-Extension-119:1 upstream v119, first release Tero-Datadog-Extension-119:2 patch on top of upstream v119 Tero-Datadog-Extension-120:1 upstream v120 The upstream number is then exact in every region from the first publish, with no filler versions, and a new region needs no catch-up - which matters for the pending us-west-2 and EU rollout. The layer version integer becomes the patch number, so v119.2 is expressible. Tag v119 to publish the next patch, or v119.2 to assert it lands on 2. The assertion runs before publishing, because a layer version cannot be renumbered once it exists. Version parsing lives in scripts/parse_release_version.sh with a --self-test, since a wrong number here is not reversible. The workflow_dispatch input now reaches the script through env rather than shell interpolation. Releasing.md documented layer names that no longer existed (Datadog-Extension-Tero) and an IAM resource prefix that does not match what the workflow publishes; both are corrected. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dom asked for us-west-2 now and all US and EU regions longer term. The region list was a workflow_dispatch default of us-east-1, so a tag release reached one region. Add a DEFAULT_REGIONS env var as the single source of truth: the four US regions plus the five EU regions AWS enables by default. Both fallbacks now read it, and the input defaults to empty so there is one list, not three. Opt-in regions (eu-south-1, eu-south-2, eu-central-2) are left out: a publish to a region the account has not enabled fails the job. They are named in a comment for when they are enabled. This is cheap now only because the upstream version moved into the layer name. Under the old counter-alignment scheme each new region needed ~95 filler versions per architecture to catch up. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds upstream-release-watch.yml: a daily cron, also runnable by hand, that checks whether we match DataDog's latest release and moves whichever half is behind. It compares two things against upstream's latest v<N>: the version main contains, recorded in the new .upstream-version file, and whether Tero-Datadog-Extension-<N> is published. Behind on code opens a merge PR; level but unpublished triggers a release; otherwise it does nothing. A release only fires after a human merged the upstream PR, so CI has been green. A conflicted merge opens an issue rather than a PR — resolving an upstream merge takes judgement, as v99 showed: stale Cargo.lock entries, a regenerated licence file, and a signature change that compiled on neither side alone. release-extension.yml gains a workflow_call trigger so the watch can invoke it directly. A tag pushed with GITHUB_TOKEN does not trigger another workflow, so tagging alone would never publish. github.event_name is the caller's event, so a scheduled run skips the -dev suffix and publishes a real release. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
smithclay
approved these changes
Aug 20, 2026
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
2 participants
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.
Please include Jira ticket in title.
Overview
Testing