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

fix(release): Update backport action to override team_reviews #6136

Merged
merged 1 commit into from
Nov 15, 2024

Conversation

Chickensoupwithrice
Copy link
Contributor

@Chickensoupwithrice Chickensoupwithrice commented Nov 15, 2024

@kalan was debugging the Backport action here, and found a bug.

We previously always attached the review to the release team, but that team is not a collaborator here in the Cody repo.
We could add them as collaborators, but that doesn't give us any benefit.

So instead I've changed the way the backport GHA works, and made the team_reviews a parameter. Here we override it to set no team. This means that only the original author and / or merger of the PR will be tagged in the new backport PR.

Test plan

Add the label to this PR, and it should create a new PR that backports this one, without errors

Changelog

N/A

Copy link
Contributor

@kalanchan kalanchan left a comment

Choose a reason for hiding this comment

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

thank you!

@Chickensoupwithrice Chickensoupwithrice merged commit 3978bdd into main Nov 15, 2024
18 of 20 checks passed
@Chickensoupwithrice Chickensoupwithrice deleted the al/CODY-4318/update-backport branch November 15, 2024 23:51
@sourcegraph-release-bot
Copy link
Collaborator

The backport to vscode-v1.44.x failed at https://github.com/sourcegraph/cody/actions/runs/11865173309:

Reviews may only be requested from collaborators. One or more of the teams you specified is not a collaborator of the sourcegraph/cody repository.

To backport this PR manually, you can either:

Via the sg tool

Use the sg backport command to backport your commit to the release branch.

sg backport -r vscode-v1.44.x -p 6136
Via your terminal

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-vscode-v1.44.x vscode-v1.44.x
# Navigate to the new working tree
cd .worktrees/backport-vscode-v1.44.x
# Create a new branch
git switch --create backport-6136-to-vscode-v1.44.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 3978bdd9c78b558611efd91bfcc5abe94e31cb73
# Push it to GitHub
git push --set-upstream origin backport-6136-to-vscode-v1.44.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-vscode-v1.44.x

If you encouter conflict, first resolve the conflict and stage all files, then run the commands below:

git cherry-pick --continue
# Push it to GitHub
git push --set-upstream origin backport-6136-to-vscode-v1.44.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-vscode-v1.44.x
  • Follow above instructions to backport the commit.
  • Create a pull request where the base branch is vscode-v1.44.x and the compare/head branch is backport-6136-to-vscode-v1.44.x., click here to create the pull request.

Once the pull request has been created, please ensure the following:

  • Make sure to tag @sourcegraph/release in the pull request description.

  • kindly remove the release-blocker from this pull request.

Chickensoupwithrice added a commit to sourcegraph/jetbrains that referenced this pull request Nov 16, 2024
Clone of the Cody PR #6136, so that we don't have failing backports

## Test plan
Tested on the [Cody repo](sourcegraph/cody#6136)
<!-- All pull requests REQUIRE a test plan:
https://sourcegraph.com/docs/dev/background-information/testing_principles

Why does it matter?

These test plans are there to demonstrate that are following industry
standards which are important or critical for our customers.
They might be read by customers or an auditor. There are meant be simple
and easy to read. Simply explain what you did to ensure
your changes are correct!

Here are a non exhaustive list of test plan examples to help you:

- Making changes on a given feature or component:
- "Covered by existing tests" or "CI" for the shortest possible plan if
there is zero ambiguity
  - "Added new tests"
- "Manually tested" (if non trivial, share some output, logs, or
screenshot)
- Updating docs:
  - "previewed locally"
  - share a screenshot if you want to be thorough
- Updating deps, that would typically fail immediately in CI if
incorrect
  - "CI"
  - "locally tested"
-->
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.

3 participants