githubnext / githubnext/tsikit-learn

Evergreen workflow startup_failure: tsikit-learn lacks access to the 'ubuntu-slim' runner group

Open
#21 0 comments 1 reaction 2 assignees Claimed by @mrjf View on GitHub
Dominant language
TypeScript
Stars
1
Forks
1
PR merge metrics
No merged PRs in 30d

Description

## Symptom

The Evergreen — PR Health Keeper workflow fails immediately with `startup_failure` — no jobs run, no log is produced.

- Failing scheduled run: https://github.com/githubnext/tsikit-learn/actions/runs/26066619680
- Failing manual dispatch: https://github.com/githubnext/tsikit-learn/actions/runs/26067088200
- Started failing after: PR #20 (gh-aw v0.74.4 upgrade)

## Root cause

All gh-aw-emitted jobs in `.github/workflows/evergreen.lock.yml` (and `autoloop.lock.yml`) target `runs-on: ubuntu-slim`:

```
$ grep -n "runs-on:" .github/workflows/evergreen.lock.yml
82: runs-on: ubuntu-slim
338: runs-on: ubuntu-latest
1013: runs-on: ubuntu-slim
1165: runs-on: ubuntu-latest
1368: runs-on: ubuntu-slim
1446: runs-on: ubuntu-slim
```

`ubuntu-slim` is **not** a stock GitHub-hosted runner label. It's a custom runner — almost certainly an org-level larger-runner or runner group managed under `githubnext`. When GitHub Actions can't match the label to a runner the calling repo is allowed to use, the workflow fails at dispatch with `startup_failure` and produces no log.

**Verification:** tsb has the byte-identical lock file (same v0.74.4 compiler output, same `ubuntu-slim` labels) and its runs succeed — meaning tsb is in the runner group's allowed-repositories list. tsikit-learn isn't.

## Fix — pick one

**Option A (simplest): grant tsikit-learn access to the `ubuntu-slim` runner group.**

Requires org admin in `githubnext`. In **Settings → Actions → Runner groups**, locate the group exposing `ubuntu-slim`, and add `tsikit-learn` to its repository access list.

**Option B: override the runner label in the workflow source so the lock file uses a stock runner.**

In `.github/workflows/evergreen.md` (and `.github/workflows/autoloop.md`) frontmatter, set:

```yaml
runs-on: ubuntu-latest
```

(or whichever stock label is appropriate). Then recompile with `gh aw compile`. Verify with:

```
grep "runs-on:" .github/workflows/*.lock.yml
```

All occurrences should be `ubuntu-latest` (or your chosen label) — no more `ubuntu-slim`.

## Confirmation in the run UI

The run pages (URLs above) should display a banner like:

> No hosted runner is currently matching the labels: `ubuntu-slim`. The job requires a runner with these labels but no runner is currently online with them.

That confirms the diagnosis.

## What this issue is NOT

An earlier draft of this issue (and the actionlint output) flagged `queue: max`, `copilot-requests`, and `vulnerability-alerts` keys in the lock file. Those are real lint warnings (worth reporting upstream to gh-aw separately), but **GitHub Actions tolerates them** — they are not the cause of `startup_failure`. tsb has the same keys in its lock file and runs fine.

## Related (separate upstream concern)

The lock file emitted by gh-aw v0.74.4 contains keys actionlint flags as invalid:

- `concurrency.queue: max` (line 1022) — only `group`/`cancel-in-progress` are valid keys
- `permissions.copilot-requests: write` (lines 344, 1168) — not a valid permission scope
- `permissions.vulnerability-alerts: read` (line 355) — not a valid permission scope

These don't break anything today (Actions silently ignores them) but should be filed upstream against `github/gh-aw` to clean up emit output.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.