Running shipjs on GitHub Actions

[uetchy]

Describe the bug
Failed to push tag to the repo while shipjs trigger.

https://github.com/uetchy/create-whatever/commit/2670594b2cb0b5635c00067da67d2e6bb262735e/checks?check_suite_id=257704743#step:7:36

To Reproduce
Run shipjs on GitHub Actions with this workflow config.

jobs:
  build:
    name: Build
    runs-on: Ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - uses: actions/setup-node@master
      - uses: geertvdc/setup-hub@master
      - run: git switch master
      - run: yarn install
      - run: yarn release:trigger
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }}

Environment (please complete the following information):

• Ship.js version: 0.6.0

Additional context

• NPM_AUTH_TOKEN and GITHUB_TOKEN has been set.

[eunjae-lee]

I just realised I should remove the part where it prints the command with the github token.
By the way, on your log, is the token automatically masked by GitHub action? or did you set *** as a token?

[uetchy]

@eunjae-lee Masked automatically by GitHub and replaced with "***". So don't worry!

[eunjae-lee]

Trying to figure out but I guess I'll probably have some time to dig into this in the weekend.

[uetchy]

shipjs prepare also fails on GitHub Actions, keeping failing to detect hub even though hub --version returns the correct response:

https://github.com/vibranthq/opinionated-review/commit/59d20c1edbaec7eb7fc00b9bbac9864d3ee38189/checks?check_suite_id=283146363

Because running hub api user with GITHUB_TOKEN, automatically issued by GitHub Actions, is prohibited as it's server-to-server token. I got a message something like this:

{"message":"Resource not accessible by integration","documentation_url":"https://developer.github.com/v3/users/#get-the-authenticated-user"}

[uetchy]

How about hub api -XPOST repos/<user>/<repo>/releases for verifying token?
If given GITHUB_TOKEN is granted to create a release for such repository, it returns:

{"message":"Invalid request.\n\nFor 'links/0/schema', nil is not an object.","documentation_url":"https://developer.github.com/v3/repos/releases/#create-a-release"}

If not, you'll get this:

{"message":"Not Found","documentation_url":"https://developer.github.com/v3/repos/releases/#create-a-release"}

shipjs/packages/shipjs/src/helper/hubConfigured.js

Line 6 in 4fac2e8

`yes "" | GITHUB_TOKEN=${process.env.GITHUB_TOKEN || ''} hub api user`,

[eunjae-lee]

Hi @uetchy ,
Thanks for digging this issue.

Your suggestion might work.
I will test that command and will come up with a PR.
Then could you test it on your side if you don't mind?

[uetchy]

@eunjae-lee Sure thing!

[eunjae-lee]

@uetchy I guess this is the same issue with ours: https://github.community/t5/GitHub-API-Development-and/Resource-not-accessible-by-integration-when-requesting-GitHub/m-p/14027#M182

And the solution is this: https://developer.github.com/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps/#user-to-server-requests

If I understand it correctly, we should use "user-to-server requests" instead of "server-to-server requests".

So we could pick any "user-to-server requests" among the list. Like you said creating a release is definitely one of them.
But here's a thing that confuses me. What about "Get the authenticated user"?
It's in the list. And it's supposed to be called like this: hub api -XGET https://api.github.com/user.

Then does it mean that hub api -XGET https://api.github.com/user is a user-to-server request and hub api user is a server-to-server request? I don't see a difference here 😵

[uetchy]

That's confusing 😮
For instance, commenting on issue/pr is surely user-to-server request though, GitHub Actions is allowed to do since GITHUB_TOKEN is authenticated as github-actions bot user (see).
api.github.com/user must be a sole exception to those that can be accessed from that token.

[uetchy]

this post might be helpful.

Adding Accept: application/vnd.github.machine-man-preview+json header

Also this

Permission	Access type	Access by forked repos
checks	read/write	read
contents	read/write	read
deployments	read/write	read
issues	read/write	read
metadata	read	read
packages	read/write	read
pull requests	read/write	read
repository projects	read/write	read
statuses	read/write	read

[eunjae-lee]

Hey @uetchy,
I'm taking some time off from OSS things(This isn't my official work, but a kind of side project).
I'll get back to this next week.