Actually, there seems to be a problem with file permissions. I will fix this later today.

Testing on the fork has concluded, this workflow is now green and ready for review

I think I'll add macOS CI in another PR after this one.

Definitely feel free to squash all these commits, they turned out to be more than I anticipated.

Might as well add ubuntu-20.04 too.

Good point, will do!

It's included now, CI is testing here: https://github.com/shinyblink/Ndless/runs/945763481?check_suite_focus=true
Currently going through a full toolchain build for all three platforms (in parallel), should be done in ~45min

Should be ready for review now. Really this time.

I'm curious, what are those security reasons?

Runners have access to tokens that allow you to do various privileged things to the repository.
To avoid me (or anyone else) from just extracting them with a malicious workflow submitted through a PR, CI does not run on PRs that originate from forks.

Now building: https://github.com/shinyblink/Ndless/actions/runs/196238815

This includes another full toolchain rebuild, because the cache paths have changed (now also includes the toolchain install directory so we can use it directly).

I'm curious, what are those security reasons?

Runners have access to tokens that allow you to do various privileged things to the repository.
To avoid me (or anyone else) from just extracting them with a malicious workflow submitted through a PR, CI does not run on PRs that originate from forks.

Note that this got improved 2 days ago :) https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

I'm curious, what are those security reasons?

Runners have access to tokens that allow you to do various privileged things to the repository.
To avoid me (or anyone else) from just extracting them with a malicious workflow submitted through a PR, CI does not run on PRs that originate from forks.

Note that this got improved 2 days ago :) https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

I'm pretty sure CIs other than GitHub's NIH had that figured out from the start already... That blog post doesn't tell how it's looking for free public organizations and repos and on github.com, maybe that's still broken?

Any update?

I've asked @alberthdev to check if he can help finish this, too, it would be great to have this CI :)

Thanks for reminding me, @adriweb :)

Should be good now - CI times without the toolchain upload are down to 60-90 seconds. I'd say that is acceptable :)

When this is merged (and when I get around to it), I'm going to take a shot at macOS CI and put out another PR with that.

rebased on top of r2016 (also master as of now), CI in progress here: https://github.com/shinyblink/Ndless/actions/runs/290422251

Was asked to take a look at this - changes as they stand today look pretty good! You're also protected from this issue, of which I'll need to update sooner rather than later as well for another project...

Some comments addressing stuff mentioned above:

• Security - it might help to filter on the event's activity types, at least from the perspective of only allowing activity types that a maintainer can actually trigger, e.g. labeling "ready-for-ci" or similar. See: pull_request event
• Other platforms - if the resulting GitHub Actions is different enough that it can't really be easily done in one file, it's not a bad idea to make those distinct. Example would be if we're trying to build on Windows - that could maybe be done in this one (and only use WSL to build), or in a separate file with a build matrix toggling on or off the WSL build step. No strong opinion here though...
• Older Linux - probably best to leave Docker out of the mix for now, if we ever add it maybe as a separate actions workflow file too. I'd (half-jokingly) suggest that if supporting older Linux distros is of interest, running this image could be fruitful: https://github.com/pypa/manylinux - and we could sort of rely on their judgement for maintenance. (Bonus if the resulting toolchain / binaries were outputted through actions/upload-artifact... then "many Linux users" would be able to run as well!)

It's looking good now! But before I merge, I have one question about GitHub actions: If someone makes a PR to master with a changed workflows/main.yml file, which one would the action run with which token with what permissions for which repo?

@Vogtinator no secret tokens are available in PRs (although they will be available in the creator's fork). If you merge them, however, they will become available.