This issue tracks submitting the following concurrency increase request to GitHub Support.
Support ticket title
Request to increase GitHub Actions concurrency for xgo-dev/llgo — 50 total jobs / 20 macOS jobs
Support ticket body
Hello GitHub Support,
We maintain xgo-dev/llgo, a public open-source project.
We would like to request an increase in standard GitHub-hosted runner concurrency for the xgo-dev organization, used primarily by the xgo-dev/llgo repository.
Requested limits:
- Total concurrent jobs: 50
- Maximum concurrent macOS jobs: 20, included in the total above
The organization is currently on the GitHub Free plan, whose documented standard runner limits are 20 total concurrent jobs and 5 concurrent macOS jobs.
About LLGo
LLGo is an LLVM-based Go compiler and a subproject of XGo. Its goal is to preserve Go source compatibility, progressively improve compatibility with the official Go standard library, and make the broader C ecosystem directly accessible to Go and XGo programs through C-compatible ABIs.
The project already provides:
- Go-like build, run, test, and install workflows
- Direct C and C++ interoperability
- Python ABI bindings and generated packages, including integrations with libraries such as NumPy, pandas, PyTorch, and Matplotlib
- A growing Go standard-library compatibility and coverage suite
- Native Linux and macOS compiler/runtime coverage
- Cross-compilation and embedded target profiles and commands
- WASI runtime testing and js/wasm build validation
Python interoperability is already usable today. JavaScript interoperability is currently experimental and is being developed together with the WebAssembly runtime.
Our next development stages include:
- Closing the remaining Go standard-library and runtime compatibility gaps
- Supporting additional Go versions and toolchain combinations
- Strengthening native Linux and macOS support across architectures
- Expanding embedded platform coverage
- Expanding WASI and JavaScript/WebAssembly runtime coverage
- Automating integration with more C and C++ ecosystem libraries
These targets require real platform-specific testing. In particular, Darwin runtime behavior, Mach-O generation, ABI behavior, linking, debugging, and native dependencies cannot be validated by Linux runners alone.
Current CI pressure
At the time of this request, a typical full pull request triggers approximately 9 workflows and 39 GitHub-hosted runner jobs:
- Approximately 26 Linux/Ubuntu jobs
- Approximately 13 macOS jobs
The current 5-job macOS limit means that even one pull request must pass through at least three batches of macOS jobs. When pull requests and updates to main overlap, every active pull request experiences runner queues.
Here are representative examples from PR #2237:
In these cases, most of the pull-request wall-clock time was spent waiting for runner capacity rather than compiling or testing.
Optimizations already made
We are actively reducing CI demand rather than relying only on a higher limit:
- Most workflows cancel superseded runs from the same pull request or branch.
llgo test uses bounded package-level parallelism inside the test command.- Ubuntu testing has been reduced to two shards.
- macOS package testing has been reduced to one primary shard.
- Redundant macOS compatibility coverage has been removed or moved to lighter release smoke tests.
- Build and dependency caching are used.
- Parallel build improvements are also in progress.
- We continue to preserve standard-library test coverage while reducing duplicate jobs.
These optimizations have shortened execution time and reduced shard count, but they cannot remove the required platform and toolchain matrix.
Why 50 total and 20 macOS
A full pull request currently contains about 39 runner jobs, including about 13 macOS jobs.
A limit of 50 total jobs would allow one complete pull-request matrix to make progress while leaving bounded capacity for main, release, or targeted validation jobs.
A limit of 20 macOS jobs would allow one current pull-request matrix plus essential main or release validation without allowing two unrestricted full macOS matrices at once.
The matrix will grow as LLGo expands native, embedded, and WebAssembly coverage, so the requested limits also provide reasonable near-term capacity without being unbounded.
We will continue using cancellation, bounded internal parallelism, reduced shards, and CI utilization monitoring. This request is specifically for job concurrency; we are not requesting additional artifact storage.
Could you please increase the xgo-dev organization’s standard GitHub-hosted runner limits to:
- 50 total concurrent jobs
- 20 concurrent macOS jobs
If the full increase cannot be granted immediately, we would appreciate guidance on a staged or temporary open-source project increase.
Thank you for your consideration.
This issue tracks submitting the following concurrency increase request to GitHub Support.
Support ticket title
Request to increase GitHub Actions concurrency for xgo-dev/llgo — 50 total jobs / 20 macOS jobs
Support ticket body
Hello GitHub Support,
We maintain xgo-dev/llgo, a public open-source project.
We would like to request an increase in standard GitHub-hosted runner concurrency for the
xgo-devorganization, used primarily by thexgo-dev/llgorepository.Requested limits:
The organization is currently on the GitHub Free plan, whose documented standard runner limits are 20 total concurrent jobs and 5 concurrent macOS jobs.
About LLGo
LLGo is an LLVM-based Go compiler and a subproject of XGo. Its goal is to preserve Go source compatibility, progressively improve compatibility with the official Go standard library, and make the broader C ecosystem directly accessible to Go and XGo programs through C-compatible ABIs.
The project already provides:
Python interoperability is already usable today. JavaScript interoperability is currently experimental and is being developed together with the WebAssembly runtime.
Our next development stages include:
These targets require real platform-specific testing. In particular, Darwin runtime behavior, Mach-O generation, ABI behavior, linking, debugging, and native dependencies cannot be validated by Linux runners alone.
Current CI pressure
At the time of this request, a typical full pull request triggers approximately 9 workflows and 39 GitHub-hosted runner jobs:
The current 5-job macOS limit means that even one pull request must pass through at least three batches of macOS jobs. When pull requests and updates to
mainoverlap, every active pull request experiences runner queues.Here are representative examples from PR #2237:
In these cases, most of the pull-request wall-clock time was spent waiting for runner capacity rather than compiling or testing.
Optimizations already made
We are actively reducing CI demand rather than relying only on a higher limit:
llgo testuses bounded package-level parallelism inside the test command.These optimizations have shortened execution time and reduced shard count, but they cannot remove the required platform and toolchain matrix.
Why 50 total and 20 macOS
A full pull request currently contains about 39 runner jobs, including about 13 macOS jobs.
A limit of 50 total jobs would allow one complete pull-request matrix to make progress while leaving bounded capacity for
main, release, or targeted validation jobs.A limit of 20 macOS jobs would allow one current pull-request matrix plus essential
mainor release validation without allowing two unrestricted full macOS matrices at once.The matrix will grow as LLGo expands native, embedded, and WebAssembly coverage, so the requested limits also provide reasonable near-term capacity without being unbounded.
We will continue using cancellation, bounded internal parallelism, reduced shards, and CI utilization monitoring. This request is specifically for job concurrency; we are not requesting additional artifact storage.
Could you please increase the
xgo-devorganization’s standard GitHub-hosted runner limits to:If the full increase cannot be granted immediately, we would appreciate guidance on a staged or temporary open-source project increase.
Thank you for your consideration.