8000 Replace legacy build-bot automation with GHAs · Issue #10403 · kgateway-dev/kgateway · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Replace legacy build-bot automation with GHAs #10403

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
4 tasks
timflannagan opened this issue Dec 13, 2024 · 3 comments
Open
4 tasks

Replace legacy build-bot automation with GHAs #10403

timflannagan opened this issue Dec 13, 2024 · 3 comments
Labels
Type: Tech Debt

Comments

@timflannagan
Copy link
Member
timflannagan commented Dec 13, 2024 •
edited
Loading

Do you have a suggestion for code improvement or tracking existing technical debt? Please describe.

The k8sgateway repository (and the interim-maintained Gloo fork) currently relies on the legacy build-bot automation. This setup utilizes Google Cloud Builders to handle release management and run several testing suites for PR presubmit checks. However, this approach presents several challenges:

  • Unmaintained Repository: The build-bot repository is no longer actively maintained
  • Dependency on Solo's Google Cloud Account: Reliance on Solo's Google Cloud account introduces maintenance overhead and friction for contributors

Additionally, the majority of CI automation has been migrated to GHAs over time, so replacing build-bot with GHA workflows helps provide consistency with the rest of existing CI automation, while lowering the barrier of entry for onboarding new developers by eliminating the need to learn and maintain legacy tooling.

Describe the solution you'd like

Replace any buildbot functionality that's still being utilized in this repository with GHAs.

  • Replicate the ci/cloudbuild/run-tests.yaml tests in the GHA presubmit workflows
  • Audit the ci/cloudbuild/publish-artifacts.yaml to determine how much overlap (if any) we have with existing release management
  • Remove the root cloudbuild*.yaml and .gcloudignore (?) files, the ci/cloudbuild directory, etc. from the repository
  • Remove any references to cloudbuild throughout the repository (e.g. markdown or .gitignore entries)

Open Questions:

  • Do we want to migrate over the run-hashicorp-e2e-tests Makefile target target over?
  • Do we want to replicate the GH slash commands that build-bot supports or implement this over time as a follow-up?
  • Do we want to emulate the build-bot release functionality that moved changelogs in open PRs to the next location when a new tag was cut. Blocked on how we want to approach changelog management in this repository going forward
  • Are there any changes to the tilt configuration that need to be made?

Additional Context

See #10363 for more information.
@timflannagan
Copy link
Member Author

Open question on whether we want to continue supporting the / commands (e.g. /kick) that build-bot supports. I'm guessing this is in scope for this change as devs are already familiar with that workflow. Alternatively, we keep this issue scoped to automating the core functionality that build-bot was previously leveraging, and re-evaluate over time whether the slash commands need to be re-introduced to alleviate any devex issues.

@timflannagan
Copy link
Member Author

Similarly, another open question on replicating the automation that moved changelog entries to the next directory when a tag has been cut. I think that still makes sense w.r.t. but it's dependent on whether we're switch our approach to changelog management in this repository going forward.

@timflannagan
Copy link
Member Author

Talked with some folks and the consensus is that we don't need to do this immediately:

  • Yuval's open PR does not require any testing suites that buildbot runs
  • We don't have an immediate need for release management until we get the project up-and-running

Additionally, there's some open questions w.r.t. where release artifacts are stored. Previously, we stored them in our bucket and that would need to change as well.

@timflannagan timflannagan mentioned this issue Dec 17, 2024
Closed
@timflannagan timflannagan mentioned this issue Jan 10, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Tech Debt
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@timflannagan
0