auto shipit uses wrong token/user to push commits in Git

[thuringia]

First of all, thank you for releasing auto, it is quite a pleasure to use and the prevention of commit message bike-shedding is a godsend!

Describe the bug

It looks like auto shipit is not using the GH_TOKEN to authenticate its push to our private repo and org:

npm notice integrity:     sha512-kXkHqsVqSmGJl[...]cfW+F0SWxcjBg==
npm notice total files:   57                                      
npm notice 

Error: Running command 'git' with args [push, --follow-tags, --set-upstream, https://github.com/COMPANY/REPO, master] failed

remote: error: GH006: Protected branch update failed for refs/heads/master.        
remote: error: At least 1 approving review is required by reviewers with write access.        
To https://github.com/finanzcheck/traversal-editor
 * [new tag]         v0.6.5 -> v0.6.5
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to 'https://github.com/COMPANY/REPO'

    at ChildProcess.<anonymous> (/home/runner/work/REPO/REPO/node_modules/@auto-it/core/dist/utils/exec-promise.js:49:24)
    at ChildProcess.emit (events.js:311:20)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
##[error]Process completed with exit code 1.

We are using a Bot user's token as GH_TOKEN, NPM_TOKEN and NODE_AUTH_TOKEN with the correct scopes, and it is an admin of the repo. Status checks and review requirements still seem to apply though, regardless of the value of "Include administrators" in the branch restrictions.

We have verified that pushing directly that the bot user can push commits directly to master. We also tried using tokens of two developers and ran into the same issue.

Interesting detail, the Github workflow executes "correctly" when pushing directly to master. It still fails to push commits but the script does not error:

npm notice 
+ @COMPANY/REPO@0.6.2
remote: error: GH006: Protected branch update failed for refs/heads/master.        
remote: error: At least 1 approving review is required by reviewers with write access.        
To https://github.com/COMPANY/REPO.git
 * [new tag]         v0.6.2 -> v0.6.2
 ! [remote rejected] master -> master (protected branch hook declined)
error: failed to push some refs to '***github.com/COMPANY/REPO.git'
ℹ  info      Current "Latest Release" on Github: v0.6.1
ℹ  info      Using release notes:
#### ⚠️  Pushed to `master`

- COMMIT

#### Authors: 1

- AUTHOR
ℹ  info      Releasing v0.6.2 to GitHub.

auto shipit works fine for PRs, which is weird, as the Github workflow is identical, except for some if conditions based on pr labels.

To Reproduce

1. Activate review restrictions and status checks for branch

2. Push branch, and open PR

3. Run auto shipit on PR

4. Accept PR

5. Run auto shipit on master -> fails

6. Push directly to master

7. Run auto shipit -> works-ish, the push still fails, but the script does not error

Expected behavior

Push does not fail

Screenshots

Environment information:

Environment Information:

"auto" version: v9.15.2
"git"  version: v2.25.0
"node" version: v13.8.0

Project Information:

✔ Repository:      COMPANY/REPO
✔ Author Name:     Robert Wawrzyniak
✔ Author Email:    [redacted]
✔ Current Version: v0.6.6
✔ Latest Release:  v0.6.2

✔ Labels configured on GitHub project

GitHub Token Information:

✔ Token:            [Token starting with 52ba]
✔ Repo Permission:  admin
✔ User:             thuringia
✔ API:              https://api.github.com
✔ Enabled Scopes:   gist, notifications, read:packages, repo, write:packages
✔ Rate Limit:       4997/5000

✨  Done in 42.03s.
Time: 0h:00m:43s

Additional context

Here is the Github workflow executing auto:

name: Release on master

on:
  push:
    branches:
      - master

jobs:
  release:
    runs-on: ubuntu-latest
    if: "!contains(github.event.head_commit.message , 'ci skip') && !contains(github.event.head_commit.message, 'skip ci')"
    steps:
      - uses: actions/checkout@v2
      - run: git fetch --prune --unshallow --tags

      - uses: actions/setup-node@v1
        with:
          node-version: "12.x"
          registry-url: "https://npm.pkg.github.com/"
          scope: "@COMPANY"

      - id: yarn-cache-dir
        run: echo "::set-output name=dir::$(yarn cache dir)"
      - uses: actions/cache@v1
        id: yarn-cache
        with:
          path: ${{ steps.yarn-cache-dir.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - run: yarn install
        env:
          NODE_AUTH_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}

      - uses: actions/cache@v1
        with:
          path: ${{ steps.yarn-cache-dir.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - name: Create Release
        env:
          GH_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
        run: |
          yarn install --frozen-lockfile
          yarn build:library
          yarn autorelease
        # yarn build: library runs babel
        # yarn autorelease is just "auto shipit" 

[hipstersmoothie]

Has this ever worked before? I recently fiddled with code that could effect this.

[hipstersmoothie]

BTW Thanks for the great issue writeup!

[thuringia]

I'm not sure this ever worked to be honest 😆

I was working with Gitlab for the past year or so… So different rules for PRs and such

Let me know, if I can help you debug this, or support you otherwise

[thuringia]

After some trial and error I was able to further clarify potential root causes, one could be auto-related the other may be an issue with Github itself.

We managed to get pushing using a similar trick to the one mentioned in #945 to modify the git origin.
However it still did not work… unless we disable the requirement for PR approvals in the branch protections…… Which shouldn't be an issue as we're using an admin-level user, but here we are.

Correction: It is no longer working if status checks are required. Github branch protections are definitely an issue. I have to disable PR approvals and status checks for now

The git origin could be addressed by auto using the GH_TOKEN to authenticate its push, maybe behind a feature flag or something. The other may require some documentation and working around Github.

Do you think such a setting would be a good idea for auto?

For reference, we can push correctly using this URL:
git remote add origin "https://$GH_TOKEN@github.com/COMPANY/REPO"

[thuringia]

@hipstersmoothie I see what you mean with "fiddeling" (#1036) 😀 This fixes most of the problem, thank you so much!

Did you test this with branch predictions enabled? I'm getting kind of anxious touching this menu 😆

[hipstersmoothie]

I did not test with branch protection enabled. But if it were to fail for that reason I think all you would need to do is add your own GH_TOKEN with repo permission

[hipstersmoothie]

I'll test real quick on https://github.com/hipstersmoothie/create-check

[hipstersmoothie]

Getting your error https://github.com/hipstersmoothie/create-check/runs/495554019

[hipstersmoothie]

Seems like this is an issue with GitHub actions. https://github.community/t5/GitHub-Actions/Allowing-github-actions-bot-to-push-to-protected-branch/td-p/34367

semantic-release/github#175 (comment)

Seems like the solutions are:

1. Uncheck the include administrators option Protected branch with PR requirement prevents release semantic-release/github#175 (comment) (didn't work 😢)
2. Make a GH_TOKEN on an administrators account with repo permissions and use that instead of GH_TOKEN

It's unfortunate that you cannot add the bot as an admin.

[hipstersmoothie]

I'm having a lot of trouble getting anything to work :(

[hipstersmoothie]

Lots of people want this though. https://github.community/t5/GitHub-Actions/How-to-push-to-protected-branches-in-a-GitHub-Action/td-p/29609

[hipstersmoothie]

Hmm oddly I can get checkoutv1 to work but not checkout v2

[hipstersmoothie]

works

      - uses: actions/checkout@v1

      - name: Prepare repository
        run: git checkout "${GITHUB_REF:11}"

doesn't work

      - uses: actions/checkout@v2

      - name: Prepare repository
        run: git fetch --prune --unshallow

[hipstersmoothie]

@thuringia Can you try v9.19.3 and add the following to you action?

    steps:
      - uses: actions/checkout@v2
        with:
          # Make sure to get all the commits
          fetch-depth: 0

      - name: Prepare repository
        # Fetch the rest of the git info (tags)
        run: git fetch --prune

      - name: Unset header
        # checkout@v2 adds a header that makes branch protection report errors ):
        run: git config --local --unset http.https://github.com/.extraheader

[thuringia]

@hipstersmoothie Everything is working now 😃

That additional header is quite interesting, I haven't seen that one mentioned much.

One side-effect of removing the header seems to be that pushing without an explicit credential no longer works:
fatal: could not read Username for 'https://github.com': No such device or address

Replacing most of the release script with auto shipit fixes this though:

export PATH=$(npm bin):$PATH

VERSION=`auto version`

## Support for label 'skip-release'
if [ ! -z "$VERSION" ]; then
  yarn auto shipit
fi

Thank you so much for the quick help!

[hipstersmoothie]

auto shipit does that version check for you. So all you need to do is run just auto shipit 🎉 No script needed

[adierkens]

🚀 Issue was released in v9.19.4 🚀