Set up GitHub Actions

[jonas-schievink]

No description provided.

[rust-highfive]

r? @adamgreig

(rust_highfive has picked a reviewer for you, use r? to override)

[jonas-schievink]

bors try

[jonas-schievink]

bors try

[bors]

try

Already running a review

[jonas-schievink]

bors try-

[jonas-schievink]

bors try

[bors]

try

Build succeeded:

• rustfmt
• ci-linux (stable)
• ci-linux (1.38.0)

[jonas-schievink]

@adamgreig ready for review :)

[adamgreig]

Thank you so much!! Looks good, couple of nits. Only shame is that merging this to master won't help #275 finally merge, sigh.

[adamgreig]

Ok, looks good to me. My only remaining concern is a policy one around whether we want to enforce rustfmt by failing PRs that don't have it run; we don't currently do this on any (I think?) wg repos. I know it's a tired fight but I at least don't want it to happen de facto. Sadly there's presumably not many good options...

• allowing CI to pass despite rustfmt failure makes it basically meaningless
• no current way to have bors or github apply rustfmt for us
• not doing it presumably means users with auto-rustfmt will keep adding accidental formatting changes to their PRs until it's all rustfmt-clean anyway

I don't auto-rustfmt so I'm sort of meh about the whole situation but I don't think I can muster any compelling arguments against.

On another note, I see the Clippy run fails because the PR is from a fork; do we expect that will work after this PR is merged, or should we change the clippy template too? I know GHA supports running the base branch's CI workflow on the PR's git commit, which might allow clippy annotations for PRs-from-forks, but maybe this will already work since it's what we're using elsewhere (or maybe it doesn't work elsewhere either, and we don't notice when making non-fork PRs?).

[jonas-schievink]

I see the Clippy run fails because the PR is from a fork; do we expect that will work after this PR is merged, or should we change the clippy template too?

This unfortunately fundamentally doesn't work on GitHub Actions. I think the Clippy action will write the clippy output to the console instead though.

[adamgreig]

This unfortunately fundamentally doesn't work on GitHub Actions. I think the Clippy action will write the clippy output to the console instead though.

Ah, I see for example over on probe-rs that's what we get (e.g.). I wonder if it's possible if we use pull_request_target instead of pull_request, which gives access to secrets to the action and might allow clippy to post annotations. I've used it in stm32-rs to be able to push generated files to another repository triggered by PRs from forks. Anyway we can experiment with it later, there's no need for it to block this.

[adamgreig]

Oh, we already do rustfmt on cortex-m-rt, so that fight has been and gone. Let's do this!

bors merge

[jonas-schievink]

I wonder if it's possible if we use pull_request_target instead of pull_request, which gives access to secrets to the action and might allow clippy to post annotations.

Oh, sounds like they added this specifically for clippy-style actions, neat!

[bors]

Build succeeded:

• ci-linux (1.38.0)
• ci-linux (stable)
• rustfmt