chore: Move to GitHub Action for deploy

[nschonni]

This can use the built-in token so forks can leverage this without setup. This also limits the deployment to when affected files are pushed to the main branch, instead of for any change.

You can find an example of the run here https://github.com/nschonni/aria-practices/runs/1005120239?check_suite_focus=true as I included my testing branch while I was developing this

[mcking65]

I feel grossly ignorant here. I have some things to learn. So, these might be silly questions.

This can use the built-in token so forks can leverage this without setup.

This is sort of mysterious to me ... what are the built-in tokens? What is their purpose? I don't understand how it is different from what we are doing now. Say I fork the repo, what does it change for me? How do I benefit?

This also limits the deployment to when affected files are pushed to the main branch, instead of for any change.

What does this mean? I especially do not understand the "instead" part.

Start with the very basics ... I assume that deploy in this context means build from master and replace what is in gh-pages. Does this currently happen when files are pushed to a branch other than master?

[nschonni]

The overall docs for GitHub Actions are over here on their new docs site https://docs.github.com/en/actions. That said, I find their docs a little underwhelming a lot of the time, and I end up just searching each time I'm trying to do something new.

This is sort of mysterious to me ... what are the built-in tokens? What is their purpose?

Here is the topic that talks about the build in token that the GitHub Action runner automatically creates https://docs.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token.

Say I fork the repo, what does it change for me? How do I benefit?

So today with the Travis setup, someone forking, the deploy script fails if you don't create your own personal access token and add it to your repo to get the gh-pages script not to short-curcuit.

What does this mean? I especially do not understand the "instead" part.

Here are the main docs for the path filtering https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths. In the current Travis setup, a job is kicked off, no matter what files are changed in a push, but with this, a job is only created if the pushes contain paths that match the filter. EX: if you changed and pushed to master a change to something in the CONTRIBUTING.md, no job would be created, but if something in the examlpes or common are changed, then a job is queued.

Does this currently happen when files are pushed to a branch other than master?

No, the current filter on the Travis config is here https://github.com/w3c/aria-practices/blob/master/.travis.yml#L67. In the GitHub Action, that behaviour of only deploying on a push to master is maintained.

[spectranaut]

This looks great, thanks @nschonni -- also thanks for the detail explanation and links to gh docs :)

[spectranaut]

Hmm I thought we would have to include - coverage/** but it looks like we don't actually publish the coverage pages. @mcking65 is it intentional that we don't publish the coverage report?

[mcking65]

Yes, this is intentional ... they don't belong in the APG. I've considered putting them on the wiki at major milestones. Might do that as we finalize 1.2.

[nschonni]

No problem, if this lands, I'll try and go back to #1385 and break it up into separate PRs

[nschonni]

Oops, it looks like you've marked the gh-pages branch as protected https://github.com/w3c/aria-practices/runs/1014707098?check_suite_focus=true#step:7:14

[mcking65]

How do we fix that? Not sure we want to unprotect it.

[mcking65]

Should I revert?

[nschonni]

Protected branches can be used to prevent against force pushes, to require reviews, or require status checks to pass before they can merge https://docs.github.com/en/github/administering-a-repository/about-protected-branches.
I don't think that really applies to gh-pages branch as it is a generate branch based off the build. I'm not sure if anyone else besides @michael-n-cooper has admin access here to update it or not

[nschonni]

Should I revert?

Unless you want to land something to be pushed to gh-pages right now, I think we can probably work through the protected branch stuff

[mcking65]

@nschonni

I believe we should keep gh-pages protected. We have it protected so we can enable branch restrictions. We don't want anyone to be able to push to our editor's draft without going through our review process. Only members of the editor's team can push with branch restrictions enabled.

Does this mean we can't use GitHub actions for deploy?

[nschonni]

You can still provide another token to the checkout to allow the push back like https://github.com/canada-ca/ore-ero/blob/32637f8960ecd25b589f80afba53e9e0aa88085b/.github/workflows/dependencies.yml#L19-L22

I'm not sure if there is a fallback syntax to conditionally use the normal GitHub Action token for everyone else working on their own forks. I'll take a look and see if a basic || will work for that

[nschonni]

The || didn't work directly for the value on the checkout, but I think I got it working in #1504, but it will need for someone to set a token on this repo

[mcking65]

@nschonni thank you! I can't add the secret, but I sent a note to Michael to get his help. Hope we'll be all good after merging 1504.