8000 Release automation · Issue #18 · eclipse-score/docs-as-code · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Release automation #18

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
AlexanderLanin opened this issue May 9, 2025 · 8000 9 comments
Open

Release automation #18

AlexanderLanin opened this issue May 9, 2025 · 9 comments
Assignees
@Aymen-Soussi-01

Comments

@AlexanderLanin
Copy link
Member
AlexanderLanin commented May 9, 2025 •
edited by MaximilianSoerenPollak
Loading

Currently releases involve some manual steps:

  • Create tag in this repository
  • Create release in this repository
  • Create PR in bazel_registry repository
  • Create PR in user repositories (will be handled by renovatebot in the future)
  • Create a script/workflow that creates automatic PRs whenever there is a new tooling repository tag
  • Create a way to introduce changelogs

Can we automate/simplify any of this?
@MaximilianSoerenPollak
Copy link
Contributor

This might be of interest here:

https://github.com/goreleaser/goreleaser (Our stuff doesn't have to be written in Go, just the name of the tool is that way)

@Aymen-Soussi-01 Aymen-Soussi-01 moved this from Todo to In Progress in Infrastructure May 13, 2025
@Aymen-Soussi-01 Aymen-Soussi-01 self-assigned this May 13, 2025
@Aymen-Soussi-01
Copy link
Contributor
Aymen-Soussi-01 commented May 14, 2025 •
edited
Loading

Proposal for Automating Releases in Our Tooling Workflow

Our current release process involves several manual steps across repositories. While GoReleaser was initially considered, it is designed around Go projects and typical public release pipelines (e.g., GitHub + Homebrew + Docker + Git tags + GitHub releases), and is not ideal for our needs.

Our use case is Python-based, not targeting PyPI, and instead focused on internal delivery to a Bazel registry, with synchronized updates to other internal and user repositories. Based on this, here's a breakdown of relevant tools and a comparison of how well they support our specific requirements.

Recommended Tools

  • GitHub Actions: Flexible automation platform, handles tagging, release creation, CI workflows, PR creation via gh CLI, and Bazel-related scripts.
  • Release Drafter: Automatically generates changelogs and populates GitHub release drafts based on PR metadata and labels.
  • Custom Shell/Python Scripts: To update version files, Bazel manifests, or internal configuration.
  • RenovateBot: For propagating version bumps in dependent user repositories automatically.

Comparison Table

Feature / Tool GitHub Actions Release Drafter Hatch Poetry RenovateBot GoReleaser
Tag creation Yes No Optional No No Yes
Release generation Yes Yes (draft) No No No Yes
Changelog support Scriptable Yes No No No Limited
PR creation in core repo Yes (via CLI) No Scriptable Manual No No
PRs in user repos Optional No No No Yes No
Bazel-specific integration Yes (custom) N/A No No No No
PyPI publishing No No Yes Yes No Yes
Internal registry compatibility Yes (custom) N/A No No N/A No

Conclusion: The best combination for our needs is:

  • GitHub Actions: Core automation engine for tagging, triggering workflows, release creation, changelog integration, and opening PRs.
  • Release Drafter: To generate release notes automatically from PR metadata.
  • Custom scripts: For updating Bazel files and coordinating internal registry releases.
  • RenovateBot: To keep user repositories updated with the latest versions once tagging is complete.

This combination avoids PyPI and gives us full control over internal tooling delivery with minimal manual effort.

@MaximilianSoerenPollak
Copy link
Contributor

Need to re-evaluate the tools for our specific usecase, as we do not want to release to pypi but instead to our local bazel registry & the repositories etc.

Closed
3 tasks
@Aymen-Soussi-01
Copy link
Contributor

@MaximilianSoerenPollak I updated the investigation on top to avoid the repetition

@AlexanderLanin
Copy link
Member Author

Looking at the table I don’t understand the recommendation: Why should we use poetry or hatch if they don’t help us?

@Aymen-Soussi-01
Copy link
Contributor
Aymen-Soussi-01 commented May 21, 2025 •
edited
Loading

@AlexanderLanin I updated the investigation now, and I removed the unnecessary tools from the recommendation section as they do support PyPI.

@MaximilianSoerenPollak
Copy link
Contributor

The question I think that is important to figure out here, you write about using 'custom scripts' for some of these jobs.
How are we going to run them?
How are we going to deploy / develop / test them?
What exactly do they need to do (in this scenario), and what expertise do we need for this?

Just to state it, what we would like the 'release part' to do is basically this:

  1. Create a new release with relevant Changelog
  2. Make a PR to 'bazel_registry' with new release (copy MODULE.bazel, add the version to metadata.json, and change source.json)

And then the 'renovate bot' can check the latest registry entry and make a PR to bump the versions in the Repos if they use an older one.

I'm a bit skeptical that it will be 'minimal manual effort' to write all of those scripts etc. but I haven't looked into ti much so maybe possible.

@AlexanderLanin
Copy link
Member Author

Maybe parts are possible via scripting gh-cli. Alternatively via github graphql lib.

@Aymen-Soussi-01
Copy link
Contributor

@MaximilianSoerenPollak here is a response to your concerns

Script Responsibilities

The scripts are there to bridge the workflow gaps GitHub Actions and Renovate don’t handle out of the box. Specifically, they'd automate:

  • Version Tag Detection: Detect the latest Git tag (new release) and extract the version.
  • Bazel Registry PR Creation:
    • Copy the updated MODULE.bazel.
    • Add the new version entry in metadata.json.
    • Update source.json to point to the new GitHub release URL.
    • Open a pull request in the bazel_registry repo with these changes.
  • Optional Validations: Ensure the release was built and tagged correctly and optionally verify Bazel can resolve the new registry entry.

Script Execution Context

The scripts will be triggered and run directly inside the GitHub Actions pipeline. Here's how it will work:

  • Trigger: A push of a new Git tag or a manual dispatch event.
  • Runner: GitHub-hosted Ubuntu runners.
  • Execution: Use standard Bash or Python scripts inside the workflow.
  • Authentication: Use GH_TOKEN or scoped GITHUB_TOKEN for PR creation.

This setup keeps everything within CI/CD—no external bot apps, no elevated GitHub App privileges.

Script Development and Testing

Scripts should be:

  • Stored in the repository (e.g., under .github/scripts/).
  • Modular: Break into small functions (e.g., tag detection, file editing, PR creation).
  • Testable locally: Add dry-run flags, environment vars, and sample inputs for local testing.
  • Optionally include test harnesses (e.g., pytest) to simulate steps with dummy data.

Required Expertise

  • Intermediate Python or Bash scripting.
  • Familiarity with GitHub Actions syntax and Git CLI operations.
  • Understanding of JSON file manipulation (e.g., jq, Python’s json module).
  • Basic understanding of Bazel module metadata files.

Effort Considerations

It’s true that the initial implementation will require time and care. But once in place:

  • Release tagging can automatically trigger the process.
  • The bazel_registry is updated accurately and consistently.
  • RenovateBot can operate as intended without manual intervention or project-specific hacks.

This reduces long-term friction, avoids human errors, and ensures releases are reproducible and traceable—especially valuable in a foundation-governed environment.

Summary

By centralizing custom scripting inside GitHub Actions, keeping the logic scoped and repo-local, and avoiding external automation dependencies, we can deliver a reliable, low-friction automation layer. It takes some initial work, but the payoff is a streamlined, reproducible release pipeline tailored to our ecosystem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Aymen-Soussi-01 Aymen-Soussi-01

Labels
None yet
Projects
Infrastructure
Status: In Progress
Milestone
No milestone
Development

No branches or pull requests
3 participants
@AlexanderLanin @MaximilianSoerenPollak @Aymen-Soussi-01
0