Skip to content

feat(release): Enhance build and publish workflows#4473

Open
radTuti wants to merge 8 commits intotigera:masterfrom
radTuti:reltool-hooks
Open

feat(release): Enhance build and publish workflows#4473
radTuti wants to merge 8 commits intotigera:masterfrom
radTuti:reltool-hooks

Conversation

@radTuti
Copy link
Contributor

@radTuti radTuti commented Feb 25, 2026

Description

This implements and extensible hook system to extend the build and publish workflows. The builds for hashrelease uses the git hash for the corresponding product to generate CRDs when a path to the product directory locally is not set. For release, the publish creates a github release by default unless user overrides it.

Release Note

TBD

For PR author

  • Tests for change.
  • If changing pkg/apis/, run make gen-files
  • If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

  • Milestone set according to targeted release.
  • Appropriate labels:
    • kind/bug if this is a bugfix.
    • kind/enhancement if this is a a new feature.
    • enterprise if this PR applies to Calico Enterprise only.

Copilot AI review requested due to automatic review settings February 25, 2026 00:49
@radTuti radTuti requested a review from a team as a code owner February 25, 2026 00:49
@marvin-tigera marvin-tigera added this to the v1.42.0 milestone Feb 25, 2026
add a generic, extensible hook system to the release tooling that allows
external code to extend build and publish workflows
without modifying core logic.
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR implements an extensible hook system to enhance the build and publish workflows for the release tooling. The changes enable external code to extend workflow behavior without modifying core logic, add support for cloning product repositories at specific git hashes for hashrelease builds when local directories aren't provided, and change the default behavior to create GitHub releases during publish operations.

Changes:

  • Introduced a comprehensive hook system with timeout support for extending build and publish workflows
  • Added automatic git-based repository cloning for hashrelease builds when product directories aren't specified
  • Changed default GitHub release creation behavior from opt-in to opt-out

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 13 comments.

Show a summary per file
File Description
hack/release/hooks.go New hook system implementation with timeout and error handling
hack/release/hooks_test.go Comprehensive tests for hook system including timeout and error scenarios
hack/release/build.go Integrated hook system, added hashrelease repo cloning, refactored cleanup to use hooks
hack/release/build_test.go Tests for git hash extraction from version strings
hack/release/publish.go Integrated publish hooks, refactored to return publish status
hack/release/utils.go Added context-aware command execution, made version validator overridable
hack/release/utils_test.go Tests for context-aware commands and version validator override
hack/release/flags.go Added hook timeout, git repo/branch flags, changed GitHub release default to true
hack/release/checks.go Updated to use overridable version validator
hack/release/prep.go Updated modifyComponentImageConfig call signature
Makefile Removed explicit CREATE_GITHUB_RELEASE=true (now default)

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +136 to +138
// runCommandInDirContext is a context-aware variant of runCommandInDir.
// When ctx is cancelled, the entire process group is killed to ensure child processes are cleaned up.
func runCommandInDirContext(ctx context.Context, dir, name string, args, env []string) (string, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're starting to have so many runCommandX type functions that I wonder if we should just have one command that we pass Option()s to, like

runCommand(
    cmd.WithCommand("blah"),
    cmd.InDir("dir"),
    cmd.WithContext(ctx),
    cmd.WithEnv(env)
)

Otherwise, it might make sense to have one runCommandInDirWithContextAndOutputAndTimeout(...) command and some simplified wrappers that just pass defaults for whichever fields they don't need (e.g. runCommandInDir() passes a default ctx and timeout and discards output).

Probably not worth it for this PR but I'm not sure how difficult that would be to implement.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likely for a different PR to limit the scope for this PR.

- switch phase hook to multiHook
- clean up cloning hashrelease repo to use treeless clone instead
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants