move GITHUB_TOKEN to inputs

[yelizariev]

Pros:

• we can set required: true and other properties in action.yml and handle the argument on action level and not just in scripts
• we can check whether token is custom or built-in

It's implemented here https://github.com/stefanzweifel/git-auto-commit-action/pull/26/files, but that PR has other updates

[stefanzweifel]

@yelizariev I've created a PR for this in #35.

I've also tested this in my demo app here:
https://github.com/stefanzweifel/git-auto-commit-action-demo-app/runs/387688173

However, I'm not really convinced why this is the better or what the upsides are.
Currently it would still be possible to override the GitHub token with a personal access token (PAT) like this:

    - uses: stefanzweifel/git-auto-commit-action@master
      with:
        commit_message: Apply php-cs-fixer changes
        branch: ${{ github.head_ref }}
      env:
        GITHUB_TOKEN: my-random-token

Other projects I've seen so far all use env.GITHUB_TOKEN.

Could you elaborate the following point with some examples?

and handle the argument on action level and not just in scripts

---

Or why this action should make checks on the token?

we can check whether token is custom or built-in

[yelizariev]

we can check whether token is custom or built-in

Potential use is for choosing default values for Author and Commiter
#29

and handle the argument on action level and not just in scripts

Currently, there is no check that github token is provided. It seems, though, that the GITHUB_TOKEN is always available in the environment. While on using the input, it's explicitly specified that argument is required.

I think I tried something like in your example

    - uses: stefanzweifel/git-auto-commit-action@master
      with:
        commit_message: Apply php-cs-fixer changes
        branch: ${{ github.head_ref }}
      env:
        GITHUB_TOKEN: my-random-token

But somehow it doesn't. Not sure, though. It could be just some author\commiter behaviour.

Other projects I've seen so far all use env.GITHUB_TOKEN.

I actually got this idea from other github actions:

• github-actions-x/commit@b48217b
• maybe another one too. I cannot fine now

[stefanzweifel]

But somehow it doesn't. Not sure, though. It could be just some author\commiter behaviour.

Ah I see. I think the structure in my example might be from the old beta. The official docs now also use a similar example like you mentioned: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token#using-the-github_token-in-a-workflow

name: Pull request labeler
on:
- pull_request
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/labeler@v2
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}

---

With the release of actions/checkout@v2 we could also eliminate the whole token thing completely Example. v2 stores the credentials by default in the local git directory and allows subsequent Actions to push back to the repository.
I've prepared this in #36 (still have to update the README)

Would this change break your workflows?
I think even in scenarios where you checkout multiple repositories in 1 workflow you still can leverage the power of checkout@v2 and will be able to push to both cloned repositories.

[yelizariev]

With the release of actions/checkout@v2 we could also eliminate the whole token thing completely Example. v2 stores the credentials by default in the local git directory and allows subsequent Actions to push back to the repository.
Would this change break your workflows?

I will be able to set my custom token in checkout@v2 section. But I need to check whether issues from #28 are gone with checkout@v2 authentication. I'll test #36 in coming days

[stefanzweifel]

@yelizariev Could you already test the changes in #36? The README in the PR/branch has been updated and my tests all worked fine.

I would like to move on with this PR and merge this into v3. Will be able to close a couple of issues with this.

[yelizariev]

Stefan, I apologize for delay. I actually switched to another deployment and don't use Github Pages for now. But I'm glad to assist you with the refactoring.

...

So, I confirm that #36 closes #28

Config:

• checkout: https://github.com/itpp-labs/odoo-test-docs/blob/dc0fef86702ce62bb681c2e5c11f949b7e915317/.github/workflows/main.yml#L14-L16
• commit: https://github.com/itpp-labs/odoo-test-docs/blob/dc0fef86702ce62bb681c2e5c11f949b7e915317/.github/workflows/main.yml#L37-L46

Logs: https://github.com/itpp-labs/odoo-test-docs/runs/427059846

Commit: itpp-labs/odoo-test-docs@f9c41ce

The Deployment was triggered by the commit: https://github.com/itpp-labs/odoo-test-docs/deployments

[yelizariev]

Thanks for the work!

[stefanzweifel]

Alright. Gonna merge #36 now.