Page MenuHomeFreeBSD

Switch to environment files for Github actions
ClosedPublic

Authored by brooks on Thu, Nov 19, 11:50 PM.

Details

Summary

The set-env command was deprecated October 1st and replaced with an
environment file you can append to for use in the next job.
https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

Test Plan

Worked on CheriBSD

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 34922
Build 31939: arc lint + arc unit

Event Timeline

brooks created this revision.

LGTM, but not sure if this will break SVN->git conversion again.

This revision is now accepted and ready to land.Thu, Nov 19, 11:57 PM

LGTM, but not sure if this will break SVN->git conversion again.

Yeah we'll need to coordinate commit timing w/ uqs

The last change didn't break the converter, per se. But github was blocking the upload of the new file. As this is only changing an existing file, I think it'll be just fine (I know that pushing changes to these files with the CLI is ok, I've never had to add one of these .github/workflow files so far)

Anyway, I can club github into submission should this cause any fallout.

.github/workflows/cross-bootstrap-tools.yml
21–23

ubuntu 20's clang package brings us version 10.0 of clang, is that not sufficient? I'd also drop the ubuntu 18 run, tbh.

I might have a look at these workflows later on ... let's get this one in first.

33

Should this here and for buildkernel below be extracted to a common "setup env" step?

.github/workflows/cross-bootstrap-tools.yml
21–23

We (the CHERI project) support builds on Ubuntu 18 so we'd prefer to keep testing on 18 (it all runs in parallel and it's Microsoft's' money :). Likewise, we want to keep bootstrapping with the most recent compiler to ensure things stay working. (Our build tool prefers the devel/llvm11 port on FreeBSD at the moment).

.github/workflows/cross-bootstrap-tools.yml
21–23

11 also matches the base system, although there is also an argument for trying to compile with the oldest possible clang version (or the system packages).

Microsoft's money isn't my concern here, but rather the FreeBSD developer time, so this stuff should be as fast as possible.

Here's what I had in mind, I tried to get gcc to play ball, but gave up on that. It would be worthwhile for a buildworld, I'd say.

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

In D27290#610937, @uqs wrote:

Microsoft's money isn't my concern here, but rather the FreeBSD developer time, so this stuff should be as fast as possible.

Here's what I had in mind, I tried to get gcc to play ball, but gave up on that. It would be worthwhile for a buildworld, I'd say.

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

Looks like using the pre-installed system packages still takes 22s instead of 40ish? But if it works with system-provided packages that's probably better than installing a specific version.

I added a buildworld step to the CI and that took about 1 hours if I recall correctly, so it might be worth adding that with clang12-dev to catch new warnings.

In D27290#610937, @uqs wrote:

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

Looks like using the pre-installed system packages still takes 22s instead of 40ish? But if it works with system-provided packages that's probably better than installing a specific version.

Speaking of which. debian/ubuntu has a bmake package, it would be great if we could use that. homebrew has a bmake package as well.

We could also use a cache and store the bmake artifacts in between runs, but I haven't fully wrapped my head around caching in Travis or Github yet.

As for llvm under MacOS, it does come with AppleClang preinstalled, so we can also just use that. It's at version 12 but I failed to get it to work easily. I have no access to a macOS image, so if someone could help with the path/dir layout there, that would help much.

I added a buildworld step to the CI and that took about 1 hours if I recall correctly, so it might be worth adding that with clang12-dev to catch new warnings.

This is too long and the user base for these github actions is probably rather small anyway. The only way forward for a proper, fast, CI is to properly do incremental builds. That requires a build system that only deals with building and not with bootstrapping like the current mess we have in our Makefiles. I wish we'd rip out clang from the base system and then rip out the bootstrapping of tools from our build system so that make(1) can simply make everything, once. Moving to cmake/ninja then would likely be trivial.

In D27290#611349, @uqs wrote:
In D27290#610937, @uqs wrote:

https://github.com/uqs/freebsd/actions/runs/381511283

Also, why do we still have -fformat-extensions in our Makefiles? Am I wrong or is there no compiler out there that still knows about this flag, yes?

Looks like using the pre-installed system packages still takes 22s instead of 40ish? But if it works with system-provided packages that's probably better than installing a specific version.

Speaking of which. debian/ubuntu has a bmake package, it would be great if we could use that. homebrew has a bmake package as well.

We could also use a cache and store the bmake artifacts in between runs, but I haven't fully wrapped my head around caching in Travis or Github yet.

Last time I tried the Ubuntu bmake package it did not work, but that may have improved since. However, I think there is also value in checking the bmake version bundled in the source tree works.

As for llvm under MacOS, it does come with AppleClang preinstalled, so we can also just use that. It's at version 12 but I failed to get it to work easily. I have no access to a macOS image, so if someone could help with the path/dir layout there, that would help much.

Apple clang will not work since it lacks support for non-apple targets. For example, it's missing the linker (only MachO is supported not ELF) and I believe also does not include backends for non-native architectures. Additionally the version number does not match upstream LLVM. Apple Clang 12 appears to map to LLVM 10.

I added a buildworld step to the CI and that took about 1 hours if I recall correctly, so it might be worth adding that with clang12-dev to catch new warnings.

This is too long and the user base for these github actions is probably rather small anyway. The only way forward for a proper, fast, CI is to properly do incremental builds. That requires a build system that only deals with building and not with bootstrapping like the current mess we have in our Makefiles. I wish we'd rip out clang from the base system and then rip out the bootstrapping of tools from our build system so that make(1) can simply make everything, once. Moving to cmake/ninja then would likely be trivial.

I'd love to be able to build with ninja (finally actual incremental builds), but that will be a lot of work :(

I don't think it matters too much how longer this CI step takes, the most useful aspect of it is that it will show which commit(s) broke cross-building and that does not necessarily need to be fast.
If we want a CI on pull requests that gives feedback within minutes rather than hours we need more powerful build machines. Even if we had incremental builds, using the two free CPUs that github provides will still take a really long time for changes that touch commonly included headers.

Hmpf, this ran into the same issue as last time ...

Pushing base-head.git to github
To base.github.com:freebsd/freebsd.git
! [remote rejected] trunk -> svn_head (refusing to allow an integration to create or update workflow .github/workflows/cross-bootstrap-tools.yml)
error: failed to push some refs to 'base.github.com:freebsd/freebsd.git'