-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move build from Travis CI to GitHub Actions? #74
Comments
with support for manual triggering, see #74
This still isn't complete. Changes to the SD/MS wikis don't trigger a build. |
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? |
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. |
The config on the GitHub Action side appears to be working. I tried sending a POST using |
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. |
Yes it's absolutely possible. We can add an 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. |
If we can do this entirely in GitHub Actions, why introduce yet another dependency by using AWS? |
@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. |
@iBug That's not the issue. To be explicit, both the SD and MS accounts have admin access to this repository. |
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 doCreate a GHA workflow config that fires on Where I need helpAn access token (preferrably from smokey's account) added as a secret to both repositories. Best named 2. Put the webhook receiver on AWS Lambda:What I will doI have a GH webhook receiver already set up for my other projects so I'll simply add a route for the Where I need helpI 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. |
As to the above suggestions:
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. |
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.
Extra: Shall we move the wiki webhook receiver out from MS and put it on AWS Lambda for easier maintenance?
The text was updated successfully, but these errors were encountered: