Skip to content
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

[Backport M66] chore/build: Teach JetBrains push-git-tag-for-next-release.sh about release branches #6884

Merged
merged 1 commit into from
Jan 30, 2025

Conversation

sourcegraph-release-bot
Copy link
Collaborator

These scripts predate release branches and used to always look at global tags. This change makes it work on release branches. It uses git to list the commits on the release branch, then does the same version bump calculation using the branch's tags.

It takes care to handle newly budding branches which are just a commit on main that has no backports yet. In that case it looks at all of the available tags.

It will work carrying a branch from prerelease through to release:

# At the start of the branch
$ ./scripts/push-git-tag-for-next-release.sh --minor --nightly
# During prerelease, assume we have accumulated some commits on the branch now:
$ ./scripts/push-git-tag-for-next-release.sh --patch --nightly
# Transitioning to release:
$ ./scripts/push-git-tag-for-next-release.sh --minor
# Hopefully never needed, but making emergency patches on stable:
$ ./scripts/push-git-tag-for-next-release.sh --patch

There are some caveats with this tool:

  • When working on a release branch, it only has local view of that branch's tags. Misusing it should be harmless because creating a tag which conflicts with an existing tag will fail when the tag is pushed.
  • It does not enforce the new practice of stable builds having even version numbers and prerelease builds having odd version numbers.

If you ever need to work around this tool, just author and push git tags yourself. To this point release captains have been doing that anyway.

Adds a --dry-run option which makes testing easier. Removes outdated docs and points to Notion instead.

Test plan

# Pretend you're just cooking up a release branch
$ git remote update origin
$ git checkout -b my-release-branch origin/main
$ cd jetbrains
$ ./scripts/push-git-tag-for-next-release.sh --minor --nightly --dry-run
# It should suggest a minor version bump based on all the version tags in the repo
...
# Pretend you're on a release branch, we're doing a patch release
$ git fetch origin refs/heads/jb-v7.8.x
$ git checkout FETCH_HEAD
$ git checkout <this PR> -- scripts/next-release.sh scripts/push-git-tag-for-next-release.sh
$ git commit -m 'test test test do not push'  # script insists the repo is clean
$ ./scripts/push-git-tag-for-next-release.sh --minor --dry-run
# It should suggest v7.8.1

I am the release captain and will dogfood this script in the current release.
Backport b912145 from #6881

…elease branches (#6881)

These scripts predate release branches and used to always look at global
tags. This change makes it work on release branches. It uses git to list
the commits on the release branch, then does the same version bump
calculation using the branch's tags.

It takes care to handle newly budding branches which are just a commit
on `main` that has no backports yet. In that case it looks at all of the
available tags.

It will work carrying a branch from prerelease through to release:

```
# At the start of the branch
$ ./scripts/push-git-tag-for-next-release.sh --minor --nightly
# During prerelease, assume we have accumulated some commits on the branch now:
$ ./scripts/push-git-tag-for-next-release.sh --patch --nightly
# Transitioning to release:
$ ./scripts/push-git-tag-for-next-release.sh --minor
# Hopefully never needed, but making emergency patches on stable:
$ ./scripts/push-git-tag-for-next-release.sh --patch
```

There are some caveats with this tool:
- When working on a release branch, it only has *local* view of *that
branch's tags.* Misusing it should be harmless because creating a tag
which conflicts with an existing tag will fail when the tag is pushed.
- It does not enforce the new practice of stable builds having even
version numbers and prerelease builds having odd version numbers.

If you ever need to work around this tool, just author and push git tags
yourself. To this point release captains have been doing that anyway.

Adds a `--dry-run` option which makes testing easier. Removes outdated
docs and points to Notion instead.

## Test plan

```
# Pretend you're just cooking up a release branch
$ git remote update origin
$ git checkout -b my-release-branch origin/main
$ cd jetbrains
$ ./scripts/push-git-tag-for-next-release.sh --minor --nightly --dry-run
# It should suggest a minor version bump based on all the version tags in the repo
...
# Pretend you're on a release branch, we're doing a patch release
$ git fetch origin refs/heads/jb-v7.8.x
$ git checkout FETCH_HEAD
$ git checkout <this PR> -- scripts/next-release.sh scripts/push-git-tag-for-next-release.sh
$ git commit -m 'test test test do not push'  # script insists the repo is clean
$ ./scripts/push-git-tag-for-next-release.sh --minor --dry-run
# It should suggest v7.8.1
```

I am the release captain and will dogfood this script in the current
release.

(cherry picked from commit b912145)
@dominiccooney dominiccooney merged commit 5da55dc into M66 Jan 30, 2025
18 of 19 checks passed
@dominiccooney dominiccooney deleted the backport-6881-to-M66 branch January 30, 2025 09:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants