Skip to content

feat: introduce automated tag and release process in maintainer guide #280

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.

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

Merged
merged 4 commits into from
Aug 7, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 50 additions & 4 deletions MAINTAINER.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,12 +42,58 @@ go build ./cmd/readmevalidation && ./readmevalidation

## Making a Release

### Create Release Tags
### Automated Tag and Release Process

After merging a PR:
After merging a PR, use the automated script to create and push release tags:

1. Get the new version from the PR (shown as `old → new`)
2. Checkout the merge commit and create the tag:
**Prerequisites:**

- Ensure all module versions are updated in their respective README files (the script uses this as the source of truth)
- Make sure you have the necessary permissions to push tags to the repository

**Steps:**

1. **Checkout the merge commit:**

```bash
git checkout MERGE_COMMIT_ID
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this handle multiple unreleased modules if they are merged through multiple commits but haven't been released in a while?

I guess if we checkout the most latest merge commit the script will see all modules available (even the ones merged previously but unreleased) and tag them all at the currently checked out module.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there are previous commits that have not been released before he current commit, it would include them in the release process.

I originally thought that this might be a problem, but figured that it might ensure that we never have forgotten unreleased modules if we use this script often.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess if we wrote this into a workflow we could essentially detect it on every commit and automatically release it if I wrote in a way to suppress the confirmation message

```

2. **Run the tag release script:**

```bash
./scripts/tag_release.sh
Copy link
Preview

Copilot AI Aug 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation references ./scripts/tag_release.sh but there's no indication in this PR that the script was actually moved to the scripts directory. Consider verifying the script location or updating the path if the move hasn't occurred yet.

Suggested change
./scripts/tag_release.sh
./tag_release.sh

Copilot uses AI. Check for mistakes.

```

3. **Review and confirm:**
- The script will automatically scan all modules in the registry
- It will detect which modules need version bumps by comparing README versions to existing tags
- A summary will be displayed showing which modules need tagging
- Confirm the list is correct when prompted

4. **Automatic tagging:**
- After confirmation, the script will automatically create all necessary release tags
- Tags will be pushed to the remote repository
- The script operates on the current checked-out commit

**Example output:**

```text
🔍 Scanning all modules for missing release tags...

📦 coder/code-server: v4.1.2 (needs tag)
✅ coder/dotfiles: v1.0.5 (already tagged)

## Tags to be created:
- `release/coder/code-server/v4.1.2`

❓ Do you want to proceed with creating and pushing these release tags?
Continue? [y/N]: y
```

### Manual Process (Fallback)

If the automated script fails, you can manually tag and release modules:

```bash
# Checkout the merge commit
Expand Down
File renamed without changes.