ci(ff): support feature freeze automation#15433
Conversation
this should help with manipulating the YAML using the YAML golang library
Resolve conflicts in .mergify.yml, go.mod, and go.sum by taking upstream/main as the base and retaining PR-specific release tooling dependencies (go-git, go-github).
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
1 similar comment
|
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
Validate and allowlist repository paths before writing release files, and update tests to use supported relative manifest paths.
Allow re-running release workflows without duplicate branches, empty commits, duplicate PRs, or false version-update errors.
| } | ||
|
|
||
| // Pattern: docker.elastic.co/elastic-agent/elastic-agent:X.Y.Z | ||
| re := regexp.MustCompile(`(docker\.elastic\.co/elastic-agent/elastic-agent:)[0-9]+\.[0-9]+\.[0-9]+`) |
There was a problem hiding this comment.
Is there a way we can generalize? or at least surface the pattern to the magefile?
| return fmt.Errorf("failed to checkout existing branch: %w", err) | ||
| } | ||
|
|
||
| fmt.Printf("✓ Checked out existing branch: %s\n", branchName) |
There was a problem hiding this comment.
Do we want this? If someone creates a branch beforehand, we will checkout that and continue working, which could inject unwanted code.
| return err | ||
| } | ||
|
|
||
| dryRun := os.Getenv("DRY_RUN") == "true" |
There was a problem hiding this comment.
| dryRun := os.Getenv("DRY_RUN") == "true" | |
| var dryRun bool | |
| if v, err := strconv.ParseBool(os.Getenv("DRY_RUN")); err == nil { | |
| dryRun = v | |
| } |
maybe? or at least
| dryRun := os.Getenv("DRY_RUN") == "true" | |
| dryRun := strings.ToLower(os.Getenv("DRY_RUN")) == "true" |
Replace invalid 9.5.0-test examples with 9.6.0 and document the required version format for local release workflow testing.
Use go-git CheckoutOptions.Keep so major/minor release workflow can prepare version files before checking out the release branch.
Replace go-git AddWithOptions(All: true) with per-path staging from worktree status so CommitAll includes every changed path (including submodule gitlinks like beats) without reading submodule directories.
Match the Beats release automation by requiring GITHUB_TOKEN for push operations and authenticating via HTTP basic auth with an explicit branch refspec.
|
buildkite test this |
This comment has been minimized.
This comment has been minimized.
TL;DRThe Windows unit-test failures are a real regression in the new release tooling, independent of the Beats submodule mismatch already reported above. Remediation
Investigation detailsRoot CauseIn The tests change into a temporary directory before invoking the functions ( Evidence
VerificationNot reproduced locally because this checkout does not contain the PR branch’s new What is this? | From workflow: PR Buildkite Detective Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not. |
What does this PR do?
This PR migrates the Elastic Agent release automation from Makefile-based scripts to a pure Go implementation using Mage, eliminating external tool dependencies for the feature-freeze workflow.
Key features
DRY_RUNmode for safe testing without pushing changes or creating branchesRELEASE.mdanddev-tools/mage/release/README.mdIdempotency
Release workflow steps are safe to re-run without failing or creating duplicate side effects:
UpdateVersionversion/version.goalready has the target versionUpdateDocsUpdateMergifyCreateBranchCommitAllPushCreatePRThis makes
mage release:runMajorMinorandmage release:runPatchresilient to CI retries and partial failures.This branch is rebased on current
mainwith merge conflicts resolved ingo.mod,go.sum, and.mergify.yml.Why is it important?
Supports feature-freeze automation as part of the broader release workflow effort in #12711.
Idempotent steps reduce operational risk when automation is retried after transient failures (network, auth, or partial workflow completion).
Checklist
./changelog/fragmentsusing the changelog toolDisruptive User Impact
No user-facing impact. This affects release automation tooling used by maintainers.
How to test this PR locally
Use a valid
X.Y.Zrelease version (for example, the next planned minor release). Versions such as9.5.0-testare rejected by the tooling.To verify idempotency, run the same workflow twice; the second run should complete without errors and without duplicate branches, commits, or PRs.
Related issues
Related issue: https://github.com/elastic/observability-robots/issues/3404