Fails to create pull request when changes already committed about create-pull-request

[peter-evans]

The commit is created with GitHub [email protected] as the committer and github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> as the author to match how commits are created through the file uploader/editor on GitHub.com (or by a GitHub owned bot like Dependabot).

Interesting. I haven't seen the --author flag used before. I can probably add an input for that.

The rest of your use case seems doable with the action. Don't try to create a branch and commit before the action runs. Just modify the files locally and then let the action create and update the branch/PR.

Try this to start with. (I know it's missing the --author setting that you need)

    - name: Vendor Node Modules
      shell: bash
      run: |
        docs/scripts/configure-git.sh
        rm -r node_modules/
        rm package-lock.json
        bin/linux/x64/node/node-v12.10.0-linux-x64/bin/node bin/linux/x64/node/node-v12.10.0-linux-x64/lib/node_modules/npm/bin/npm-cli.js install --no-optional --no-bin-links --loglevel=error
        grep -rl '"_where"' node_modules/ | xargs sed -i '/_where/d'
        grep -rl '"man": \[' node_modules/ | xargs sed -i '/"man": \[/,/\],/d'
    - uses: peter-evans/create-pull-request@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        commit-message: Update Node Modules
        author-email: [email protected]
        author-name: GitHub
        title: 'Update Node Modules'
        body: |
          Update Vendored Node Modules to the latest versions found in https://github.com/${{ github.repository }}/blob/master/package.json
        labels: dependencies
        branch: actions/node-vendor
        branch-suffix: none

If this works, I can look into adding the --author flag as an input.

I do understand, though, that there could be use cases where it would make sense to control the commits before the actions runs. I'll have a think about how to support that.

[peter-evans]

@matfax I believe I know what that problem is and it's different from this issue. I'm fairly sure it's due to untracked files not being able to be popped from the stash. Would you mind creating a new issue so we can discuss it separately?

[kevinvanrijn]

Verified this works correctly when both values are specified. Build log.

---

Do note that when only the author is specified it is used for both values. The equivalent Git command (git commit --author "name <email>") would use the author specified on the flag for just the author of the commit. The committer would fall back to whoever is currently configured (or error out in a workflow). Build log.

And when only the committer is specified it uses it for only the committer, and falls back to GITHUB_ACTOR for the author. The equivalent Git command (git -c user.name="name" -c user.email="email" commit) would use it for both the author and committer Build log.

So these two behaviours are reversed with how regular Git handles them. I get that this is due to supporting the previous configuration with just the author but consider matching Git's behaviour as a breaking change for a v2 release.

---

Thanks for supporting my use case!

I'll close this issue for now, if one of the other use cases I mentioned comes up in the future a new issue can be created for those.

[peter-evans]

@kevinvanrijn Thanks for confirming it works ok for you.

You are right, I had to reverse the way Git handles author and committer because I didn't want to break the current behaviour. It's on my list of things to fix in v2!

[peter-evans]

Hi @kevinvanrijn

I would like to understand your use case and see if I can help you in any way. I'm assuming this is the workflow you have been trying the action with.
https://github.com/ModdingMinecraft/modpack-updater/blob/master/.github/workflows/node-vendor.yml

The first thing I noticed is that the commit you are making in the previous step is directly to the master branch. A pull request needs to have a branch and base. In most cases you want to be committing to a new branch and raising a pull request to merge that branch into master.

Perhaps you could explain a bit more about what you are trying to do and why this action doesn't work for you. What control over the commit do you need?

[kevinvanrijn]

Correct, that's the workflow.

In my case, I'm creating a commit with different author/commiter information. While using GITHUB_ACTOR is accurate, commit ownership starts to become confusing when run as a cron job.

The commit is created with GitHub <[email protected]> as the committer and github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> as the author to match how commits are created through the file uploader/editor on GitHub.com (or by a GitHub owned bot like Dependabot).

It results in the commit actually being attributed to the github-actions bot. Instead of whoever was unfortunate enough to trigger the schedule.

As for what I'm actually trying to do. I'm trying to take the current HEAD, commit any changes made to it, push that to a branch named actions/node-vendor (creating it if it doesn't already exist), and then create/update a pull request to merge that branch into master.

My workflow shouldn't ever be on the master branch if I understand actions/checkout correctly. It should leave the cloned project in a detached HEAD state and commit on top of it.

EDIT: I see that actions/checkout has updated and no longer creates a detached HEAD. So you're correct in saying it commits directly to the master branch.

[kevinvanrijn]

Do note that there are more use cases why you would create a commit yourself though.

Just to name a few things:

• Different author and committer (my use case)
• Creating more than one commit (seperating changes to make it easier to review)
• Creating commits in the past (archival purposes)
• Anything created with git commit-tree. (For complex tasks like git-reparent)
• Merge (or octopus) commits (even though I don't think these belong in a pull request they're still a valid use case and might be useful for pulling in the history from a separate project)

[kevinvanrijn]

I did some more testing and it appears it doesn't make a difference if the current HEAD is a detached state or not.

Creating the actions/node-vendor branch first, which I thought you hinted at in your comment fails with: fatal: A branch named 'actions/node-vendor' already exists.

It looks like create-pull-request is executing git checkout -b (which doesn't override an existing branch) instead of git checkout -B (which would). Is this intentional?

Build log.

[matfax]

Hi Peter,

I'm facing the same issue. My use case is a reformatting of the codebase and pushing it into a PR.
If the codebase changes and the PR has not yet been merged, an update of the existing PR seems to be appropriate, so I'm using the branch-suffix: none option here.
However, new changes from the master branch are not correctly detected. My guess is that the checkout of the master branch makes the local branch "undirty" by discarding changes on the rebase or merge. The two branches are definitely different but not detected. As a result, the existing PR is shown with conflicts.

An alternative option would be a force push. The commits themselves only include changes. If other files are affected so that there would be no conflict, the commits won't change, are thus equal and do not need to be pushed. A force push has the advantage that there is only one commit to compare against. Either that commit is different or it is not.

Here my log:

Currently checked out base assumed to be branch 'master'
Pull request branch to create/update set to 'black'
Pull request branch 'black' already exists as remote branch 'origin/black'
Checking out branch 'black'
Checking for local working copy changes indicating a diff with existing pull request branch 'origin/black' # local black and origin/black are different
No modified or untracked files detected. Skipping.

[kevinvanrijn]

@peter-evans The updated workflow works with both @v1 (Build log) and @master (Build log) and correctly force-pushes when a newer commit comes around.

Now the commits just have to be created with github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> on the --author flag again. Thanks for all the help thus far!

I'll also mention that it's possible to commit without changing the Git config or setting any environment variables (which might simplify the code slightly): git -c user.name="name" -c user.email="email" commit --author="name <email>" -m "Commit message"

---

Off-topic

I was intentionally using the latest master. My repo already depends on cloudscraper (which breaks often), so my repo ends up being the one place where I want to hit as many breaking changes as soon as possible in an attempt to keep future breakage (that I might be slow to respond to) to a minimum.

[peter-evans]

Great! I'll work on adding an input for the --author flag.

Also, I agree that I shouldn't be changing the git config and just passing flags for the user name and email. I realised that recently and I'm planning to change it.

[peter-evans]

Released a new version. You can now set author and committer as follows.

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          author-name: github-actions[bot]
          author-email: 41898282+github-actions[bot]@users.noreply.github.com
          committer-name: GitHub
          committer-email: [email protected]

Thanks for letting me know about this. I really want to make this the default if no author or committer inputs are passed to the action. That will be for v2 I think.

I saw your comment about using master. That's fine, but be aware that if I do release new major versions in future your builds are likely to break.