Skip to content

Conversation

@jsafrane
Copy link
Contributor

@jsafrane jsafrane commented Oct 21, 2025

The command performs a rebase of an OpenShift fork of an upstream repo to the latest upstream release.

Example of output: openshift/aws-ebs-csi-driver#294. I heavily edited the PR description, claude does not follow the instructions well :-(. But when it comes to cherry picking and squashing commits and resolving conflicts, it's pretty solid.

New example: openshift/csi-external-snapshotter#189
No edits in the PR description.

The command performs a rebase of an OpenShift fork of an upstream repo to
the latest upstream release.
@theobarberbany
Copy link

theobarberbany commented Oct 21, 2025

I'm not entirely sure this is a good idea for a task a Claude slash command should be taking on. Especially given agents can ignore instructions, for something as critical as a rebase we don't want to introduce agentic uncertainty :(

Have we considered implications if this fails silently / hallucinates?

We also have rebasebot already, that does something very similar? https://github.com/openshift-eng/rebasebot

@gnufied
Copy link

gnufied commented Oct 21, 2025

Yeah, so the main concern is - for larger rebases where it is hard to verify commits individually without doing full rebase yourself, it will be hard to ascertain correctness of a rebase performed via LLM.

@jsafrane
Copy link
Contributor Author

jsafrane commented Oct 22, 2025

In the storage repos, we usually have just a single <carry> patch with Dockerfiles and similar OCP specific files. Rarely we have a handful of upstream cherry picks. For such low number of commits, claude was good enough. We still need to review the cherry picks anyway, even when using rebasebot.

What I found useful was:

  • Resolving simple conflicts in the carry patches. We often delete the whole upstream .github directory to remove upstream PR templates or dependabot configs. Rebase then always conflicts. It's trivial to resolve - just delete upstream changes, but it's annoying.
  • Finding the upstream changelogs + distilling some high level summary from them. Sure, I still need to go through the changelogs manually to review the summary, but so far it was pretty good.

What is not so great:

  • Claude sometimes links upstream tags instead of changelogs. It usually needs a gentle nudge to fix it.
  • Claude formats the final PR text differently each time. It even forgets to add a section (e.g. list of carry patches).

@mpatlasov
Copy link
Contributor

/lgtm

@openshift-ci
Copy link

openshift-ci bot commented Oct 23, 2025

@mpatlasov: changing LGTM is restricted to collaborators

In response to this:

/lgtm

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Make sure they are links to changelogs, not tags.
Print list of the links.

14. Create a github pull request against the OpenShift github repository.
Copy link
Contributor

Choose a reason for hiding this comment

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

don't you need to specify a "remote" to create the PR from?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, claude is smart enough.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is a write operation, I think it would be a sensible guardrail to be explicit about always pushing against the user remote and never pushing against the openshift/upstream remote. I've seen claude pushing against my openshift remote instead of my fork when using commands that create PRs.

Also how should claude prefer to create the PR? via GH cli? mcp? should this be part of ### Pre-requisites?

Copy link

@theobarberbany theobarberbany Oct 23, 2025

Choose a reason for hiding this comment

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

I have a light preference for GH Cli, MCP exhausts context quickly (as does each tool invocation) and these commands are predictable :)


7. Find the merge base of the `openshift/master` and `$previous_tag` by running `git merge-base openshift/master $previous_tag`. We will use this merge base as `$mergebase`.

8. Prepare `commits.tsv` tab-separated values file containing the set of carry
Copy link
Contributor

Choose a reason for hiding this comment

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

should steps 1..8 be a bash scripted skill to favor determinism and reduce changes of claude derailing? cc @theobarberbany

Copy link

@theobarberbany theobarberbany Oct 23, 2025

Choose a reason for hiding this comment

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

Yeah, I think I would take that approach here. I think hooks (if appropriate) and scripting deterministic steps instead of prompt glue is generally a better approach!

UserPromptSubmit should be able to hook in at the start of the invocation of the command, hopefully making this more predictable :)

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think there's a claude code native way to scope hooks to specific commands within a plugin though. Let's leave this aside this PR and evaluate if we want to introduce a handcrafted pattern for that separately. Let's ship it, learn by use it and iterate

@enxebre
Copy link
Contributor

enxebre commented Oct 23, 2025

@enxebre
Copy link
Contributor

enxebre commented Oct 24, 2025

/label tide/merge-method-squash
/approve
/lgtm

@openshift-ci openshift-ci bot added the tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges. label Oct 24, 2025
@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Oct 24, 2025
@openshift-ci
Copy link

openshift-ci bot commented Oct 24, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enxebre, jsafrane, mpatlasov

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 24, 2025
@openshift-merge-bot openshift-merge-bot bot merged commit 681ca28 into openshift-eng:main Oct 24, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. tide/merge-method-squash Denotes a PR that should be squashed by tide when it merges.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants