Using GitHub Actions for Releasing

Project Infrastructure GitHub
21

macOS-Nightly.cmake

A few points to concern:

  • What’s the minimum macOS version requirement?
  • Do we ship libC?
22

Of course it heavily depends on the configuration and set of targets that you want to build, but you definitely need ccache or you’ll quickly run into the 6h runtime limit on the free hosted runners.
Also you’ll quickly run out of the very limited disk space that’s available (at least on Linux some parts of the runner image can be deleted to free up some space but I think on Windows you’re out of luck there).
This also affects ccache since the cache size needs to be big enough to hold 1 full set of object files which can be large e.g. for a gcc LTO build.
A modules enabled build is significantly faster but the feature only gets tested on a few Mac buildbots and is really unstable on Linux.

Here are my previous experiments:

23

You can build a Windows toolchain, though without debug info (no PDBs) and no LTO. I have had this building for a while: swift-build/swift-toolchain.yml at master · compnerd/swift-build · GitHub

24

I think we all need to agree on a build-preset first

25

I don’t think that a preset that is consistent should be a pre-requisite. Unless I’m mistaken, I don’t see people being happy to drop the use of symlinks and instead copying full binaries. However, that is not reasonable on Windows - the symlinks require elevated privilleges and the installer system (MSIs) cannot package symbolic links, so you would need a post-install C++ implementatio to create symlinks, which needs elevated privileges which would prevent per-use installation.

26

Yeah but we could at least agree on more generic stuff like what backends to ship on each platform, do we want lldb on Windows, lld on macOS? PGO Anyone? Z3? etc etc

27

The set of platforms supported by GitHub Actions in the official runner is quite limited, but we’ve had a lot of success with ChristopherHX/github-act-runner: act as self-hosted runner on unsupported platforms (e.g. AArch64/FreeBSD). If we had a mechanism like this for organisations such as Linaro, the {Free,Net}BSD Foundations, and so on to contribute runners to do nightly builds then this would make it easier to have automated builds for more platforms.

I’d recommend having a separate action for each target, because that makes it easier to ensure that, for example, the Apple signing key is provided only to the Apple builders and not accidentally leaked in other jobs.

1 Like
28

Disclaimer: I do Rust. The Rust community offers nightly builds:

> rustup update

They build the nightlies for many platforms in CI with docker:

29

Again, I don’t think that works. As an example, ncurses support should not be present, it is not available on Windows (which will mean that lldb doesn’t get many of the usability bits that people, including myself, want). What we should be agreeing on is that each platform makes the best choice for the platform. The differences can be reduced over time, but we have had those differences for ages. Each platform can configure the builds as appropriate, ideally with cmake caches that are checked in.

30

Proposed patch for building binaries with GitHub Actions is here: ⚙ D143535 github: Add manual workflow to build and upload release binaries

1 Like
31

That’s actually exactly what I meant, basically a preset for each platform we try to support, and is indeed a very complicated topic involving multiple design choices.

Speaking from macOS’s view:

  • Do we match Swift/LLVM’s distribution and ship compiler-rt and familiy for the entire Darwin ecosystem (watchOS/iOS/macOS/etc)
  • polly? OpenMP?
  • Z3 (which I do surely uses)
  • Plugin support? (Which Apple’s build disabled)