The workflow's header came over with the file from dejima-ci-hardener and describes that repository rather than this one.
It explains a split between a bats job and a compose job, the latter needing "a real Docker daemon and a real compose plugin, because the thing it checks is precisely what a stub cannot: whether what dejima-ci-runners emits is a compose file Docker will accept." There is no compose job here, and no dejima-ci-runners. The split that does exist is tests against the branch and runner-env against the machine it was handed, which each job already explains at its own definition, so the header names it in a line and stops.
Two smaller things in the same block:
It attributed the trigger behaviour to pull_request, three lines above a comment explaining at length why this file uses pull_request_target and why that difference is its whole security posture. Now says pull_request_target and points down at the reason.
It counted "the two runner-env jobs", which is true of the sister repository and not of this one.
Left alone: the privileged mentions further down, which are a real contrast between runner tiers and mean something here, and the note attributing the run-as-non-root practice to the sister repository, which is a deliberate attribution rather than an artifact.
Comments only. The diff touches no line that is not one, and 188 tests pass unchanged.
**Summary generated by LLM agent**
The workflow's header came over with the file from dejima-ci-hardener and describes that repository rather than this one.
It explains a split between a bats job and a compose job, the latter needing "a real Docker daemon and a real compose plugin, because the thing it checks is precisely what a stub cannot: whether what `dejima-ci-runners` emits is a compose file Docker will accept." There is no compose job here, and no `dejima-ci-runners`. The split that does exist is `tests` against the branch and `runner-env` against the machine it was handed, which each job already explains at its own definition, so the header names it in a line and stops.
Two smaller things in the same block:
- It attributed the trigger behaviour to `pull_request`, three lines above a comment explaining at length why this file uses `pull_request_target` and why that difference is its whole security posture. Now says `pull_request_target` and points down at the reason.
- It counted "the two runner-env jobs", which is true of the sister repository and not of this one.
Left alone: the `privileged` mentions further down, which are a real contrast between runner tiers and mean something here, and the note attributing the run-as-non-root practice to the sister repository, which is a deliberate attribution rather than an artifact.
Comments only. The diff touches no line that is not one, and 188 tests pass unchanged.
The header came over with the file from dejima-ci-hardener and described that
repository's split: a bats job and a compose job needing a real Docker daemon,
"because the thing it checks is precisely what a stub cannot: whether what
dejima-ci-runners emits is a compose file Docker will accept." There is no
compose job here and no dejima-ci-runners either. The split that does exist is
tests against the branch and runner-env against the machine, which each job
explains at its own definition, so the header names it and stops.
It also opened by attributing the trigger behaviour to `pull_request`, three
lines above a comment explaining at length why this is `pull_request_target`
and why the difference is the whole security posture of the file.
And it counted two runner-env jobs, which is true of the sister repository and
not of this one.
Comments only; the diff touches no line that is not one.
branderson
approved these changes 2026-08-29 16:43:18 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary generated by LLM agent
The workflow's header came over with the file from dejima-ci-hardener and describes that repository rather than this one.
It explains a split between a bats job and a compose job, the latter needing "a real Docker daemon and a real compose plugin, because the thing it checks is precisely what a stub cannot: whether what
dejima-ci-runnersemits is a compose file Docker will accept." There is no compose job here, and nodejima-ci-runners. The split that does exist istestsagainst the branch andrunner-envagainst the machine it was handed, which each job already explains at its own definition, so the header names it in a line and stops.Two smaller things in the same block:
pull_request, three lines above a comment explaining at length why this file usespull_request_targetand why that difference is its whole security posture. Now sayspull_request_targetand points down at the reason.Left alone: the
privilegedmentions further down, which are a real contrast between runner tiers and mean something here, and the note attributing the run-as-non-root practice to the sister repository, which is a deliberate attribution rather than an artifact.Comments only. The diff touches no line that is not one, and 188 tests pass unchanged.