Is it possible to fully restore all git state after the action?

[glasser]

Subject of the issue

I'm looking to use this action multiple times in a workflow to create a bunch of PRs for different parts of one change. That is, my workflow will run a command that changes a bunch of files, and then use this action multiple times with add-paths (and explicit branch) to create a few different PRs so that different people can apply the change to different parts of the tree.

This actually works really well, as long as the paths are all fully disjoint: the workflow will commit the specified files to the temporary branch, stash the other files, make the PR, and restore the stashed files.

However, in some cases I might want the add-paths to overlap. eg, maybe I will make one PR that's "merge all of the changes to the whole repo as one PR", a set of PRs that are per top-level directory, and a set of PRs that are per second-level directory. Depending on the level of granularity and care that is required, you can merge any set of PRs; when the workflow runs again it will helpfully close any other PRs that are now redundant.

The overall create-pull-request model supports this, but because the changes in add-paths paths vanish after a call to create-pull-request, I can't create these overlapping PRs in a simple way.

As a workaround, I can run git stash after setting up my file state, and then before each call to this action I can run git restore --source=stash@{0} -- FILES FOR THIS PR, and then not use add-paths. But it would be nice if the action just had a flag that essentially made it do this for me.

If nothing else, I'm not sure that the docs actually explain anywhere that the effect on your local git state is that you will end up back with the same branch checked out with the same commit as before you ran it, with the files matched by add-paths reset to their state from the commit, and all other local changes preserved. It's sort of implied by the add-paths documentation, but not explicitly.

Steps to reproduce

Run this workflow:

name: Make multiple PRs

on: workflow_dispatch

jobs:
  make-multiple-prs:
    concurrency: only-one-at-a-time
    runs-on: ubuntu-latest
    permissions:
      # Give GITHUB_TOKEN permissions to push.
      contents: write
      pull-requests: write

    steps:
      - uses: actions/checkout@v4

      - name: Write some files
        run: |
          echo "# another line" >>another.yaml
          echo "# more" >>values.yaml
  
      - name: Create Pull Request for another.yaml
        uses: peter-evans/create-pull-request@v5
        with:
          branch: create-pull-request/for-another.yaml
          add-paths: another.yaml
          delete-branch: true
          title: "PR for another.yaml"

      - name: Create Pull Request for values.yaml
        uses: peter-evans/create-pull-request@v5
        with:
          branch: create-pull-request/for-values.yaml
          add-paths: values.yaml
          delete-branch: true
          title: "PR for values.yaml"

      - name: Create Pull Request for all
        uses: peter-evans/create-pull-request@v5
        with:
          branch: create-pull-request/for-all
          delete-branch: true
          title: "PR for all"

You'll end up with PRs for the individual files but no PR for "all".

[peter-evans]

Hi @glasser

Thank you for reporting this issue.

I added the add-paths feature in v3 and the stash and restore in v5. When I added those features I didn't fully consider that it would make the action a bit inconsistent in the way that it leaves git state. The stash/restore is only used when add-paths is specified. For some state like git config/auth I've made an effort to revert all changes and leave the state as it was found. I think perhaps it makes sense to try and do that consistently for all git state.

I don't really want to add additional options to the action, unless it's unavoidable. I've made an effort to keep the interface simple and not bloated with config options. So I think reverting all state in every case is simple and intuitive.

I'll take a look at this change when I get a chance. It would require a major version bump, though, because potentially it would be a breaking change for some workflows that expect a particular git state after the action completes.

[glasser]

I would certainly be happy if v6 let me do the thing I wanted with zero extra configuration :)

[peter-evans]

I remember now why the non-config git state works this way. One of the features of this action is that you can make your own commits which get included in the PR. I think it's a bit too complicated (and probably undesirable) to try and restore those commits after the action completes, so I decided to just let the git state reflect anything that wasn't committed by add-paths.

I think I would prefer to leave it the way it is for now. I might change my mind in future.

There is a pretty straightforward workaround, as an alternative to the one you are already doing. Just run the Create Pull Request for all step in a separate job in parallel.

[glasser]

Makes sense. The downside to parallelizing is that constructing the file changes can be slow, so ideally that is shared across jobs. Though GH Actions does provide various ways to share state across jobs...

[peter-evans]

Closing for now.