1938bdf841
[SourceKitten](https://github.com/jpsim/SourceKitten), a popular Swift
library for interacting with SourceKit, needs to know (or be told) the
location of the sourcekitd framework. SourceKitten is somewhat
[ubiquitous](https://github.com/jpsim/SourceKitten#projects-built-with-sourcekitten);
most Swift projects I've seen or worked on used SourceKitten in some
way.
On macOS, the sourcekit framework is baked-in to the Xcode toolchain(s) and
therefore its location is generally known. On Linux, the location of the
sourcekit framework is wherever swift is installed, which is unknown to
libraries like SourceKitten.
SourceKitten searches for the sourcekit framework in [a few
locations](f7cf1e3b63/Source/SourceKittenFramework/library_wrapper.swift (L51-L104)),
but it's unable to infer the location of the framework on these ubuntu
images. The result when attempting to run any SourceKitten-based tool in
Github Actions on an ubuntu VM is the following error:
```
SourceKittenFramework/library_wrapper.swift:31: Fatal error: Loading libsourcekitdInProc.so failed
/home/runner/work/_temp/cb002a5e-1916-4e05-ba4d-f70ad3bb2266.sh: line 1: 3944 Illegal instruction (core dumped) mint run swiftlint .
```
(to be clear, this error is not specific to the Github Actions ubuntu
VMs. The same error occurs on any Ubuntu system).
Individual users can work around this by setting the following
environment variable:
```
LINUX_SOURCEKIT_LIB_PATH="/usr/share/swift/usr/lib"
```
This is not a good workaround for the following reasons:
1. The end user doesn't necessarily know where swift is installed.
2. A change to the location of the swift installation would break this
workaround.
3. The error will occur virtually 100% of the time on a user's first
attempt to run SourceKitten on ubuntu, and takes at least a
few minutes to troubleshoot. This will quickly add up to a
non-trivial amount of lost productivity.
So, anyways, my proposal is to just link sourcekitd to a location where
SourceKitten will find it, so most developers don't have to think about it.
`LINUX_SOURCEKIT_LIB_PATH` can be defined by the user if they have an
unusual setup.
Alternative:
- Don't symlink, add `LINUX_SOURCEKIT_LIB_PATH` to `/etc/environment`.
GitHub Actions Virtual Environments
Repository contains the source used to create the virtual environments for GitHub Actions hosted runners, as well as the VM images of Microsoft-hosted agents used for Azure Pipelines. To build a VM machine from this repo's source, see the instructions.
How to get in touch with us:
- To file a bug report, or request tools to be added/updated, please open an issue using the appropriate template
- If you want to share your thoughts about image configuration, installed software, or bring some idea, please, create a new topic in a discussions section for a corresponding category. Before making a new discussion please make sure no similar topics were created earlier.
For general questions about using the virtual environments or writing your Actions workflow, please open requests in the GitHub Actions Community Forum.
Available Environments
| Environment | YAML Label | Included Software | Latest Release & Rollout Progress |
|---|---|---|---|
| Ubuntu 22.04 beta | ubuntu-22.04 |
ubuntu-22.04 | |
| Ubuntu 20.04 | ubuntu-latest or ubuntu-20.04 |
ubuntu-20.04 | |
| Ubuntu 18.04 | ubuntu-18.04 |
ubuntu-18.04 | |
| macOS 12 beta | macos-12 |
macOS-12 | |
| macOS 11 | macos-latest or macos-11 |
macOS-11 | |
| macOS 10.15 | macos-10.15 |
macOS-10.15 | |
| Windows Server 2022 | windows-latest or windows-2022 |
windows-2022 | |
| Windows Server 2019 | windows-2019 |
windows-2019 | |
| Windows Server 2016 | windows-2016 |
windows-2016 |
Note: Beta and Preview images are provided "as-is", "with all faults" and "as available" and are excluded from the service level agreement and warranty. Beta and Preview images may not be covered by customer support.
What images are available for GitHub Actions and Azure DevOps? The availability of images for GitHub Actions and Azure DevOps is different. See documentation for more details:
What image version is used in my build? Usually, image deployment takes 3-4 days, and documentation in the main branch is only updated when deployment is finished. To find out which image version and what software versions are used in a specific build, see Set up job (GitHub Actions) or Initialize job (Azure DevOps) step log.
Looking for other Linux distributions? We do not plan to offer other Linux distributions. We recommend using Docker if you'd like to build using other distributions with the hosted virtual environments. Alternatively, you can leverage self-hosted runners and fully customize your environment to your needs.
How to contribute to macOS source? macOS source lives in this repository and available for everyone. However, MacOS image-generation CI doesn't support external contributions yet so we are not able to accept pull-requests for now. We are in the process of preparing MacOS CI to accept contributions. Until then, we appreciate your patience and ask you continue to make tool requests by filing issues.
Updates to virtual environments
Cadence
We typically deploy weekly updates to the software on the virtual environments. For some tools, we always install the latest at the time of the deployment; for others, we pin the tool to specific version(s).
Following Along / Change Notifications
- High Impact Changes (ex. breaking changes, new or deprecated environments) will be posted to the GitHub Changelog on our blog and on twitter.
- Low Impact Changes will be pinned in this repository and marked with the Announcement label.
- Regular Weekly Rhythm can be followed by watching Releases. Pre-release is created when deployment is started. As soon as deployment is finished, it is converted to release. You can also track upcoming changes using the awaiting-deployment label.
Software and image guidelines
To learn more about tools and images support policy, see the guidelines.