Automate manifest.json version updates during release #9
Assignees
atridad (Atridad Lahiji)
Clear assignees
atridad (Atridad Lahiji)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: atridad/Discodrome#9
Reference in New Issue
Block a user
Delete Branch "claude/automate-manifest-versioning-MJ9WM"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Automate version management during releases so the packaged artifact
always carries the correct version in
manifest.json.Changes
New
create-release.ymlworkflow — aworkflow_dispatchworkflowthat can be triggered from the GitHub Actions UI. It validates the
version format, checks for duplicate tags, runs tests, updates
manifest.json, commits, tags, and pushes — which then triggers theexisting release workflow to build and publish the artifact.
CI guard in
release.yml— fails early if the tag andmanifest.jsonversions ever diverge.Simplified
make release— instead of running the release processlocally, it now just validates the version and triggers the
create-release.ymlworkflow viagh workflow run.Summary of Changes
Hello @deluan, 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 enhances the release automation by integrating the
manifest.jsonversion update directly into themake releasecommand. This ensures that themanifest.jsonfile is always correctly versioned and committed before a release tag is created, streamlining the release process and preventing potential version mismatches in deployed artifacts. It also sets the stage for a CI check to enforce version consistency.Highlights
make releasecommand now automatically updates theversionfield inmanifest.jsonto match the release version (V) provided.manifest.jsonwith the correct version is now committed as part of the release process, ensuring the packaged artifact always reflects the intended version.git pushcommand in the release process now pushes toorigin mainin addition to the tag.🧠 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
sedcommand to automatically update theversionfield inmanifest.jsonusing theVvariable.git add manifest.jsonandgit commit -m "Release v${V}"to stage and commit the updated manifest before tagging.git pushcommand to push toorigin mainin addition to the release tag.Ignored Files
.github/workflows/**(2)Activity
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./gemini review/gemini summary/gemini helpCustomization
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.
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. ↩︎
Download the plugin for this PR: discord-rich-presence.zip
Built from
63ab3ec57eon 2026-02-08T01:16:25ZCode Review
This pull request automates the version update in
manifest.jsonduring the release process, which is a great improvement for consistency. My review points out a critical bug in the implementation that would prevent it from working as expected and provides a fix. With this correction, the change will be a valuable addition to the release workflow.@@ -16,3 +17,3 @@rm -f $(WASM_FILE) $(PLUGIN_NAME).ndprelease: testrelease:The shell variable
${V}will not be expanded within single quotes. This will result in the literal string"${V}"being written tomanifest.jsoninstead of the version number. To fix this, you should use double quotes for thesedexpression and escape the inner double quotes.Additionally,
sed -ibehaves differently on GNU/Linux versus macOS/BSD systems. For better portability, you might consider a different approach in the future, but fixing the variable expansion is the critical part.Pull request overview
This PR updates the release process to ensure
manifest.jsonis version-bumped and committed as part of creating a release tag, and adds CI validation to prevent tag/manifest version drift.Changes:
make releaseto rewritemanifest.json’sversion, commit it, then tag and push.manifest.json.Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.
make release, and pushesmain+ tag.manifest.jsonversion.💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
@@ -0,0 +1,63 @@name: Create Releasegit commit -m "Release v..."will fail the workflow ifmanifest.jsonalready contains the requested version (nothing to commit), which can happen if the workflow is re-run or the input matches the current version. Consider guarding with a diff check and skipping the commit when unchanged, or adding--allow-emptyif an empty release commit is acceptable.@@ -0,0 +35,4 @@if git ls-remote --tags origin "refs/tags/v${VERSION}" | grep -q .; thenecho "::error::Tag v${VERSION} already exists"exit 1fiThis step runs
git ls-remote ... origin ...before the repository is checked out, so it will fail with “not a git repository” / nooriginremote. Move the “Check out code” step before this, or use the GitHub API to check for an existing tag.@@ -16,6 +16,15 @@ jobs:- name: Check out codeMANIFEST_VERSIONis extracted viagrep -oPwith a PCRE-specific\K, which is brittle for JSON (and can fail if GNU grep isn’t built with PCRE support or if formatting changes). Consider parsingmanifest.jsonwith a JSON-aware tool (e.g.,jq -r .version manifest.jsonor a short Python snippet) to make this guard reliable.@@ -16,3 +17,3 @@rm -f $(WASM_FILE) $(PLUGIN_NAME).ndprelease: testrelease:git push origin main v${V}pushes the localmainref, but the release commit is created on the current checked-out branch. If the user runsmake releasefrom a branch other thanmain, the tag will point to the release commit butorigin/mainwill not receive that commit (and could even push an outdated localmain). Consider either enforcing/releases frommain(fail if not onmainandgit pull --ff-only), or pushHEAD:mainalongside the tag so the commit you just made is what gets pushed.The
releaserecipe uses bash-only syntax ([[ ... ]]/=~) and GNUsed -isemantics. Since the Makefile doesn’t setSHELL := bash, this target can fail on systems where/bin/shisdash(common on Ubuntu) or wheresed -irequires a backup suffix (macOS/BSD). Consider settingSHELL := /usr/bin/env bash(or rewriting to POSIX sh) and using a portable in-place edit approach formanifest.json.