Skip to content

Fix fork-PR CI: Runic checkout and ALCF pipeline attribution - #620

Merged
michel2323 merged 2 commits into
mainfrom
fix-fork-pr-ci
Aug 20, 2026
Merged

Fix fork-PR CI: Runic checkout and ALCF pipeline attribution#620
michel2323 merged 2 commits into
mainfrom
fix-fork-pr-ci

Conversation

@michel2323

@michel2323 michel2323 commented Aug 19, 2026

Copy link
Copy Markdown
Member
  • Runic: actions/checkout@v7 refuses fork checkouts in pull_request_target workflows without an explicit opt-in. Opt in (the PR code is only parsed, never executed), pin the head SHA, drop persisted credentials.
  • ALCF bridge: the fork-PR push uses the project access token, so the pipeline is attributed to the project's bot user, which the Jacamar runners refuse. Push with ci.skip and create the pipeline via a pipeline trigger token (ALCF_GITLAB_TRIGGER_TOKEN secret, already set) so it runs as a real user.

actions/checkout@v7 refuses to check out fork code from a
pull_request_target workflow unless explicitly opted in, so the runic
job failed before running anything. Opt in: the PR code is only parsed
by Runic, never executed. Also pin the checkout to the event's head SHA
instead of the branch name, and stop persisting credentials in the
checkout.
The label-gated fork-PR push authenticates with a project access token,
so the resulting push pipeline is attributed to the project's bot user,
and ALCF's Jacamar runners refuse those ('bot account token used for
job, unsupported by runner'), failing the pipeline before any job runs.

Push with ci.skip so no bot-attributed pipeline is created, and create
the pipeline through a pipeline trigger token instead: trigger-token
pipelines run as the user who created the token, which Jacamar accepts.
Requires a new ALCF_GITLAB_TRIGGER_TOKEN repository secret, and
.gitlab-ci.yml now accepts the 'trigger' pipeline source.
@michel2323

Copy link
Copy Markdown
Member Author

This, #618 , and #617 are stuck on an ALCF certificate issue after a maintenance window.

@codecov

codecov Bot commented Aug 20, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.47%. Comparing base (fda0805) to head (c6e57ec).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #620      +/-   ##
==========================================
+ Coverage   79.01%   80.47%   +1.46%     
==========================================
  Files          50       50              
  Lines        3488     3488              
==========================================
+ Hits         2756     2807      +51     
+ Misses        732      681      -51     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@michel2323
michel2323 merged commit cf175bf into main Aug 20, 2026
4 of 6 checks passed
@michel2323
michel2323 deleted the fix-fork-pr-ci branch August 20, 2026 14:19
michel2323 referenced this pull request Aug 21, 2026
Every kernel launch, copy, and fill used to create a fresh command list,
submit it to the task's command queue, and drop the reference — leaving
destruction of thousands of driver objects (lists, command buffers, heaps)
to finalizer timing. Under launch storms that garbage is what pushes the
driver into allocation failure, where NEO's error handling is at its worst
(the scratch path aborts outright). It is also pure overhead: the
per-dispatch list costs ~8x in submission latency.

Replace the per-dispatch machinery with a per-task oneStream holding one
in-order asynchronous immediate command list: appends submit directly, and
the garbage source disappears entirely. Level Zero >= 1.9 is required; there
is no fallback submission path.

oneMKL work still needs a real command queue for SYCL interop, so each
stream lazily creates a companion queue — a separate execution stream, which
makes the previously implicit ordering between Julia kernels and oneMKL
calls explicit: sycl_queue drains the immediate list before handing out the
SYCL queue (Julia -> MKL), and a dirty flag makes the next Julia-side
submission drain the companion queue (MKL -> Julia). FFT plans capture
their queue at construction, so their _exec! methods apply the boundary
themselves.

The LTS drain-before-free machinery follows the shape change: the queue
registry becomes a stream registry, draining both the immediate list and
the companion queue before a buffer referenced by in-flight work is freed;
immediate lists get the same bounded-drain finalizer as queues. The
sync-each-submission workaround now host-synchronizes the list after each
append. KA.priority! swaps the task's stream for one with the requested
priority. The scratch hedge moves to the stream, and remains on the
explicit-queue compatibility path (@oneapi queue=...), which still submits
through a per-dispatch list.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant