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/
Details
Details
- Reviewers
arichardson emaste uqs
Worked on CheriBSD
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 34922 Build 31939: arc lint + arc unit
Event Timeline
Comment Actions
LGTM, but not sure if this will break SVN->git conversion again.
Yeah we'll need to coordinate commit timing w/ uqs
Comment Actions
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). | |
Comment Actions
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?
Comment Actions
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.
Comment Actions
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.
Comment Actions
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.
Comment Actions
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'
Comment Actions
the env fix was committed with https://github.com/freebsd/freebsd/commit/5afe096970b19e2d3bc3b44a1a09ae788e33795c