Add pre-release support to release process #19

Merged
deluan merged 1 commits from add-prerelease-support into main 2026-03-04 11:20:46 -07:00
deluan commented 2026-03-04 11:16:20 -07:00 (Migrated from github.com)

Summary

  • Add PRE=true optional flag to make release for creating pre-releases (e.g., make release V=1.0.1 PRE=true)
  • Pre-releases are tagged as vX.X.X-prerelease and marked as pre-release in GitHub
  • Tighten version regex to prevent manual suffixes like V=1.0.0-prerelease

Test plan

  • make release V=abc fails validation
  • make release V=1.0.0-prerelease fails (tightened regex)
  • make -n release V=1.0.1 shows -f prerelease=false
  • make -n release V=1.0.1 PRE=true shows -f prerelease=true
  • Trigger a test pre-release to verify end-to-end
## Summary - Add `PRE=true` optional flag to `make release` for creating pre-releases (e.g., `make release V=1.0.1 PRE=true`) - Pre-releases are tagged as `vX.X.X-prerelease` and marked as pre-release in GitHub - Tighten version regex to prevent manual suffixes like `V=1.0.0-prerelease` ## Test plan - [ ] `make release V=abc` fails validation - [ ] `make release V=1.0.0-prerelease` fails (tightened regex) - [ ] `make -n release V=1.0.1` shows `-f prerelease=false` - [ ] `make -n release V=1.0.1 PRE=true` shows `-f prerelease=true` - [ ] Trigger a test pre-release to verify end-to-end
gemini-code-assist[bot] commented 2026-03-04 11:17:22 -07:00 (Migrated from github.com)

Summary of Changes

Hello, 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 significantly enhances the project's release workflow by integrating robust support for pre-releases. It introduces a new mechanism to trigger pre-release builds via the "make release" command, ensuring that these versions are correctly tagged and identified within GitHub. This change streamlines the process for publishing development or beta versions, improving release management flexibility.

Highlights

  • Pre-release support: Introduced an optional "PRE=true" flag to the "make release" command, enabling the creation of pre-releases.
  • Versioning and tagging: Configured pre-releases to be tagged as "vX.X.X-prerelease" and automatically marked as pre-releases in GitHub.
  • Version validation: Tightened the version regex in the Makefile to strictly enforce "X.X.X" format, preventing manual suffix additions.

🧠 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
  • Makefile
    • Modified the "release" target to accept an optional "PRE=true" argument.
    • Updated the version validation regex to only allow "X.X.X" format.
    • Adjusted the "gh workflow run" command to pass a "prerelease" flag based on the "PRE" variable.
    • Updated the success message to reflect pre-release status.
Ignored Files
  • Ignored by pattern: .github/workflows/** (1)
    • .github/workflows/create-release.yml
Activity
  • No human activity (comments, reviews, approvals) has been recorded on this pull request yet.
Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.


  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩︎

## Summary of Changes Hello, I'm Gemini Code Assist[^1]! 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 significantly enhances the project's release workflow by integrating robust support for pre-releases. It introduces a new mechanism to trigger pre-release builds via the "make release" command, ensuring that these versions are correctly tagged and identified within GitHub. This change streamlines the process for publishing development or beta versions, improving release management flexibility. ### Highlights * **Pre-release support**: Introduced an optional "PRE=true" flag to the "make release" command, enabling the creation of pre-releases. * **Versioning and tagging**: Configured pre-releases to be tagged as "vX.X.X-prerelease" and automatically marked as pre-releases in GitHub. * **Version validation**: Tightened the version regex in the Makefile to strictly enforce "X.X.X" format, preventing manual suffix additions. 🧠 **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](https://codeassist.google/code-review/login) to enable Memory in your admin console.** <details> <summary><b>Changelog</b></summary> * **Makefile** * Modified the "release" target to accept an optional "PRE=true" argument. * Updated the version validation regex to only allow "X.X.X" format. * Adjusted the "gh workflow run" command to pass a "prerelease" flag based on the "PRE" variable. * Updated the success message to reflect pre-release status. </details> <details> <summary><b>Ignored Files</b></summary> * **Ignored by pattern:** `.github/workflows/**` (1) * .github/workflows/create-release.yml </details> <details> <summary><b>Activity</b></summary> * No human activity (comments, reviews, approvals) has been recorded on this pull request yet. </details> <details> <summary><b>Using Gemini Code Assist</b></summary> <br> The full guide for Gemini Code Assist can be found on our [documentation page](https://developers.google.com/gemini-code-assist/docs/review-github-code), here are some quick tips. <b>Invoking Gemini</b> You can request assistance from Gemini at any point by creating a comment using either `/gemini <command>` or `@gemini-code-assist <command>`. Below is a summary of the supported commands on the current page. Feature | Command | Description --- | --- | --- Code Review | `/gemini review` | Performs a code review for the current pull request in its current state. Pull Request Summary | `/gemini summary` | Provides a summary of the current pull request in its current state. Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in pull request comments and review comments. Help | `/gemini help` | Displays a list of available commands. <b>Customization</b> 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 `.gemini/` folder in the base of the repository. Detailed instructions can be found [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). <b>Limitations & Feedback</b> Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: 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](https://google.qualtrics.com/jfe/form/SV_2cyuGuTWsEw84yG). <b>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](https://cloud.google.com/products/gemini/code-assist).</b> </details> [^1]: Review the [Privacy Notices](https://policies.google.com/privacy), [Generative AI Prohibited Use Policy](https://policies.google.com/terms/generative-ai/use-policy), [Terms of Service](https://policies.google.com/terms), and learn how to configure Gemini Code Assist in GitHub [here](https://developers.google.com/gemini-code-assist/docs/customize-gemini-behavior-github). Gemini can make mistakes, so double check it and [use code with caution](https://support.google.com/legal/answer/13505487).
github-actions[bot] commented 2026-03-04 11:17:30 -07:00 (Migrated from github.com)

Download the plugin for this PR: discord-rich-presence.zip

Built from 479100df3c on 2026-03-04T18:17:23Z

Download the plugin for this PR: [discord-rich-presence.zip](https://nightly.link/navidrome/discord-rich-presence-plugin/actions/runs/22682929592/discord-rich-presence.zip) Built from 479100df3c0ca7b6e9b859a720092f52c36af4de on 2026-03-04T18:17:23Z <!-- Sticky Pull Request Comment -->
copilot-pull-request-reviewer[bot] (Migrated from github.com) reviewed 2026-03-04 11:19:11 -07:00
copilot-pull-request-reviewer[bot] (Migrated from github.com) left a comment

Pull request overview

This PR adds pre-release support to the project's release process. When triggering make release, developers can now pass PRE=true to create a pre-release build tagged as vX.X.X-prerelease and marked as a pre-release in GitHub. The version regex is also tightened to prevent manual suffixes in the version argument.

Changes:

  • Makefile: Adds optional PRE=true flag; tightens version validation regex to reject suffixed versions; passes a prerelease flag to the workflow dispatch command.
  • .github/workflows/create-release.yml: Adds a prerelease boolean input, a new "Compute full version" step that appends -prerelease to the version string when applicable, and passes prerelease to softprops/action-gh-release.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
Makefile Adds PRE=true flag support, tightens version regex, and forwards prerelease flag to the GitHub Actions workflow
.github/workflows/create-release.yml Adds prerelease boolean input, computes the full version tag with optional -prerelease suffix, and marks GitHub release as pre-release
Comments suppressed due to low confidence (1)

.github/workflows/create-release.yml:70

  • When a pre-release is triggered, VERSION is set to 1.0.1-prerelease, and this full value is used to update manifest.json. This means manifest.json on the main branch will permanently have "version": "1.0.1-prerelease" committed to it. This is likely unintended — the manifest version should reflect the base semver (1.0.1), not the pre-release tag suffix. The same issue propagates to the commit message ("Release v1.0.1-prerelease" on main).

Consider using ${{ inputs.version }} (the base version without the suffix) when updating manifest.json and forming the commit message, while using $VERSION (with the suffix) only for the git tag and the GitHub release tag_name.

            - name: Update manifest.json version
              run: |
                  jq --arg v "$VERSION" '.version = $v' manifest.json > manifest.tmp && mv manifest.tmp manifest.json

            - name: Commit, tag, and push
              run: |
                  git config user.name "github-actions[bot]"
                  git config user.email "github-actions[bot]@users.noreply.github.com"
                  git add manifest.json
                  git commit --allow-empty -m "Release v${VERSION}"
                  git tag "v${VERSION}"
                  git push origin main "v${VERSION}"

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

## Pull request overview This PR adds pre-release support to the project's release process. When triggering `make release`, developers can now pass `PRE=true` to create a pre-release build tagged as `vX.X.X-prerelease` and marked as a pre-release in GitHub. The version regex is also tightened to prevent manual suffixes in the version argument. **Changes:** - `Makefile`: Adds optional `PRE=true` flag; tightens version validation regex to reject suffixed versions; passes a `prerelease` flag to the workflow dispatch command. - `.github/workflows/create-release.yml`: Adds a `prerelease` boolean input, a new "Compute full version" step that appends `-prerelease` to the version string when applicable, and passes `prerelease` to `softprops/action-gh-release`. ### Reviewed changes Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments. | File | Description | | ---- | ----------- | | `Makefile` | Adds `PRE=true` flag support, tightens version regex, and forwards `prerelease` flag to the GitHub Actions workflow | | `.github/workflows/create-release.yml` | Adds `prerelease` boolean input, computes the full version tag with optional `-prerelease` suffix, and marks GitHub release as pre-release | <details> <summary>Comments suppressed due to low confidence (1)</summary> **.github/workflows/create-release.yml:70** * When a pre-release is triggered, `VERSION` is set to `1.0.1-prerelease`, and this full value is used to update `manifest.json`. This means `manifest.json` on the `main` branch will permanently have `"version": "1.0.1-prerelease"` committed to it. This is likely unintended — the manifest version should reflect the base semver (`1.0.1`), not the pre-release tag suffix. The same issue propagates to the commit message ("Release v1.0.1-prerelease" on `main`). Consider using `${{ inputs.version }}` (the base version without the suffix) when updating `manifest.json` and forming the commit message, while using `$VERSION` (with the suffix) only for the git tag and the GitHub release `tag_name`. ``` - name: Update manifest.json version run: | jq --arg v "$VERSION" '.version = $v' manifest.json > manifest.tmp && mv manifest.tmp manifest.json - name: Commit, tag, and push run: | git config user.name "github-actions[bot]" git config user.email "github-actions[bot]@users.noreply.github.com" git add manifest.json git commit --allow-empty -m "Release v${VERSION}" git tag "v${VERSION}" git push origin main "v${VERSION}" ``` </details> --- 💡 <a href="/navidrome/discord-rich-presence-plugin/new/main?filename=.github/instructions/*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.
gemini-code-assist[bot] (Migrated from github.com) reviewed 2026-03-04 11:24:24 -07:00
gemini-code-assist[bot] (Migrated from github.com) left a comment

Code Review

This pull request adds support for creating pre-releases through the make release command by introducing an optional PRE=true flag. The changes correctly adjust the GitHub workflow invocation to pass a prerelease parameter and tighten the version string validation. However, a potential command injection vulnerability was identified in the Makefile's release target due to insecure expansion of the V variable in shell commands. It is recommended to use single quotes instead of double quotes for shell expansion of make variables to prevent unintended command execution.

## Code Review This pull request adds support for creating pre-releases through the `make release` command by introducing an optional `PRE=true` flag. The changes correctly adjust the GitHub workflow invocation to pass a `prerelease` parameter and tighten the version string validation. However, a potential command injection vulnerability was identified in the `Makefile`'s `release` target due to insecure expansion of the `V` variable in shell commands. It is recommended to use single quotes instead of double quotes for shell expansion of `make` variables to prevent unintended command execution.
gemini-code-assist[bot] (Migrated from github.com) commented 2026-03-04 11:24:24 -07:00

security-medium medium

The release target in the Makefile is vulnerable to command injection because it uses double quotes (or no quotes) when expanding the V variable in a shell command. If V contains shell command substitution like $(...) or `...`, the shell will execute the command during expansion. Although there is a regex check on line 26, the command substitution happens during the evaluation of the if condition, meaning the command executes even if the regex check fails. To remediate this, use single quotes around ${V} in the shell commands to prevent the shell from performing command substitution.

release:
	@if [[ ! '${V}' =~ ^[0-9]+\.[0-9]+\.[0-9]+$$ ]]; then echo "Usage: make release V=X.X.X [PRE=true]"; exit 1; fi
	gh workflow run create-release.yml -f version='${V}' -f prerelease=$(if $(filter true,$(PRE)),true,false)
	@echo "Release v'${V}'$(if $(filter true,$(PRE)),-prerelease,) workflow triggered. Check progress: gh run list --workflow=create-release.yml"
![security-medium](https://www.gstatic.com/codereviewagent/security-medium-priority.svg) ![medium](https://www.gstatic.com/codereviewagent/medium-priority.svg) The `release` target in the `Makefile` is vulnerable to command injection because it uses double quotes (or no quotes) when expanding the `V` variable in a shell command. If `V` contains shell command substitution like `$(...)` or `` `...` ``, the shell will execute the command during expansion. Although there is a regex check on line 26, the command substitution happens *during* the evaluation of the `if` condition, meaning the command executes even if the regex check fails. To remediate this, use single quotes around `${V}` in the shell commands to prevent the shell from performing command substitution. ``` release: @if [[ ! '${V}' =~ ^[0-9]+\.[0-9]+\.[0-9]+$$ ]]; then echo "Usage: make release V=X.X.X [PRE=true]"; exit 1; fi gh workflow run create-release.yml -f version='${V}' -f prerelease=$(if $(filter true,$(PRE)),true,false) @echo "Release v'${V}'$(if $(filter true,$(PRE)),-prerelease,) workflow triggered. Check progress: gh run list --workflow=create-release.yml" ```
Sign in to join this conversation.