Phase 25: GitHub Release Workflow — automated binary releases - #43
Conversation
Add release.yml workflow triggered by v* tags that builds flux-ftl and flux-mcp binaries for linux-x86_64, creates a GitHub Release with tar.gz archives and sha256 checksums, and a machine-readable JSON release body. ARM64 cross-compilation is commented out as a TODO due to LLVM-14/z3 native dependency complexity. Includes scripts/release.sh for convenient tag creation. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request establishes an automated release pipeline using GitHub Actions, designed to streamline the process of creating new software releases. By introducing a tag-triggered workflow and a helper script, it ensures consistent binary builds for x86_64-linux and provides structured release metadata, significantly enhancing the efficiency and reliability of our release management. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Ignored Files
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a shell script to automate the creation of release tags, which in turn triggers a GitHub release workflow. The script is well-structured and uses good shell practices like set -euo pipefail. My review focuses on improving the script's robustness and usability. I've suggested adding checks to ensure the repository is in a clean and up-to-date state before tagging, which is crucial for creating reliable releases. I've also recommended adding validation for the version string to prevent accidental malformed tags. These changes will make the release process safer and more predictable.
| # Ensure we're on main and up to date | ||
| BRANCH=$(git rev-parse --abbrev-ref HEAD) | ||
| if [ "$BRANCH" != "main" ]; then | ||
| echo "Warning: Not on main branch (currently on $BRANCH)" | ||
| read -rp "Continue anyway? [y/N] " confirm | ||
| [ "$confirm" = "y" ] || exit 1 | ||
| fi |
There was a problem hiding this comment.
The script should ensure the repository is in a clean state before creating a release tag. Currently, it doesn't check for uncommitted changes or if the local branch is synchronized with the remote. Tagging from a dirty or outdated state can lead to incorrect releases. I suggest adding checks for a clean working directory and ensuring the main branch is up-to-date with origin/main. The suggested change also improves the confirmation prompt to accept both 'y' and 'Y'.
| # Ensure we're on main and up to date | |
| BRANCH=$(git rev-parse --abbrev-ref HEAD) | |
| if [ "$BRANCH" != "main" ]; then | |
| echo "Warning: Not on main branch (currently on $BRANCH)" | |
| read -rp "Continue anyway? [y/N] " confirm | |
| [ "$confirm" = "y" ] || exit 1 | |
| fi | |
| # Ensure we're on main, up to date, and the working directory is clean | |
| if ! git diff-index --quiet HEAD --; then | |
| echo "Error: You have uncommitted changes." | |
| exit 1 | |
| fi | |
| BRANCH=$(git rev-parse --abbrev-ref HEAD) | |
| if [ "$BRANCH" = "main" ]; then | |
| echo "Fetching latest changes from origin..." | |
| git fetch origin main | |
| if [ "$(git rev-parse HEAD)" != "$(git rev-parse origin/main)" ]; then | |
| echo "Error: Your local main branch is not up to date with origin/main." | |
| exit 1 | |
| fi | |
| else | |
| echo "Warning: Not on main branch (currently on $BRANCH)." | |
| read -rp "Continue anyway? [y/N] " confirm | |
| [[ "$confirm" =~ ^[Yy]$ ]] || exit 1 | |
| fi |
| if [ -z "$VERSION" ]; then | ||
| echo "Usage: $0 <version>" | ||
| echo "Example: $0 1.0.0" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
To prevent accidental malformed release tags, it's a good practice to validate the version string provided by the user. The script currently accepts any input. I suggest adding a check to ensure the version string conforms to a semantic versioning format like 1.2.3 or 1.2.3-beta.1.
| if [ -z "$VERSION" ]; then | |
| echo "Usage: $0 <version>" | |
| echo "Example: $0 1.0.0" | |
| exit 1 | |
| fi | |
| if [ -z "$VERSION" ]; then | |
| echo "Usage: $0 <version>" | |
| echo "Example: $0 1.0.0" | |
| exit 1 | |
| fi | |
| if ! [[ "$VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9.-]+)?$ ]]; then | |
| echo "Error: Invalid version format. Expected format like 1.0.0 or 1.0.0-beta.1" | |
| exit 1 | |
| fi |
1 participant
Summary
v*Tagsscripts/release.shfür Tag-ErstellungTest plan
Closes #38
🤖 Generated with Claude Code