Charcoal-SE / charcoal-se.github.io

Website for Charcoal
https://charcoal-se.org/
8 stars 27 forks source link

Move build from Travis CI to GitHub Actions? #74

Open iBug opened 3 years ago

iBug commented 3 years ago

Recently Travis CI has shown levels of service degradation, including unnecessarily long queue times (> 1 hr) and future plans on more restrictions. On the other hand, GitHub Actions is supported by Microsoft and is believed to be more reliable in terms of usage (free forever for public repositories).

When GHA was originally introduced near the end of last year, it lacked many features so we couldn't switch. Now there is API to trigger workflows manually, it's time that we make this switch.

I have a GHA workflow file for this repo already, and the only thing left to do is to update whatever webhook receiver we have for Smokey and MS wikis to utilize the GH API. An example is provided below which is very easy to understand and port to Ruby.

curl -X POST \
  -d '{"ref": "site"}' \
  -H 'Accept: application/vnd.github.v3+json' \
  -H 'Authorization: token helloworld' \
  https://api.github.com/repos/Charcoal-SE/charcoal-se.github.io/actions/workflows/build.yml/dispatches

Extra: Shall we move the wiki webhook receiver out from MS and put it on AWS Lambda for easier maintenance?

makyen commented 3 years ago

This still isn't complete. Changes to the SD/MS wikis don't trigger a build.

iBug commented 3 years ago

Not sure what was wrong - the URL of GH API is correct, and the webhook endpoint (entrypoint) isn't touched - maybe the token on MS doesn't have admin access to this repo?

cc @Undo1 @ArtOfCode-

makyen commented 3 years ago

Please ignore my last (now deleted) comment. I stupidly was looking at the SD repo's build.yml, rather than the one for this repository.

makyen commented 3 years ago

The config on the GitHub Action side appears to be working. I tried sending a POST using curl similar to what's listed in the first comment in this Issue and the token we use for SD. Doing so did start a build. I also tried a couple of other variations on that POST, which should set the headers a bit closer to what it looks like MS is using. Both of those variations also started a build.

makyen commented 3 years ago

It looks like it's possible to trigger a build in another repository based on a trigger in a different repository.

See:

That may make it possible to trigger the site build from wiki changes in the MS and SD repositories without the involvement of MS. I still need to look into this further, so this comment is basically just a placeholder to hold the above links.

iBug commented 3 years ago

Yes it's absolutely possible. We can add an on: gollum Action in MS and SD repositories that calls the workflow_dispatch API. This is essentially moving gollum_hook from MS to GHA.

I previously proposed that we use AWS Lambda for this purpose (I can set it up as soon as I have the necessary access and/or credentials), which is again essentially the same.

makyen commented 3 years ago

If we can do this entirely in GitHub Actions, why introduce yet another dependency by using AWS?

iBug commented 3 years ago

@makyen Quick thoughts: Does @metasmoke have Admin access to this repo? If not, can you add it? I have a feeling this is the point that's blocking our move.

makyen commented 3 years ago

@iBug That's not the issue.

I tried sending a POST using curl similar to what's listed in the first comment in this Issue and the token we use for SD.

To be explicit, both the SD and MS accounts have admin access to this repository.

iBug commented 3 years ago

Now both approaches are immediately available. Here are the details.

1. Call GH API from within both SD and MS repositories using GH Actions:

What I will do

Create a GHA workflow config that fires on gollum event and calls GH API to start a new build for the website. I'll push the config to SD repo, which can be copied verbatim to MS repo.

Where I need help

An access token (preferrably from smokey's account) added as a secret to both repositories. Best named SMOKEY_TOKEN.

2. Put the webhook receiver on AWS Lambda:

What I will do

I have a GH webhook receiver already set up for my other projects so I'll simply add a route for the gollum hook for SD and MS repositories.

Where I need help

I need a token (again smokey's would suffice) for calling the API. I'll give you a webhook receiver endpoint (a URL) and the HMAC secret. You need to add this receiver to both repositories.

I'm planning to hand this out via Keybase since it's not some "top secret" as both the URL and the HMAC secret can be retrieved from repository settings.

makyen commented 3 years ago

As to the above suggestions:

  1. I don't believe this is secure. I'd have to double check, but that may open up some routes for nefarious PRs to make modifications to the repos.
  2. Creating yet another external dependency (an AWS Lambda) doesn't seem like the right thing to do. We already have MS and SD (and the MS version of SD). Adding another, while certainly possible, seems to be adding more complexity for not all that much advantage.

I'd rather fix the issue in MS, which already gets notified.

Alternately, we could add triggering the build to SD (currently the MS version of SD, but those should merge, eventually), which indirectly gets notified at the appropriate times (or at least most of them) in order to pass-through messages from MS that the CI testing passed.