#19 makes the resolved dependency graph reproducible and reddens a build on a
known vulnerability in it. Neither of those tells anybody that a dependency
moved. A lockfile nobody updates is reproducible right up to the day an advisory
lands against something inside it, and after that it is reproducibly vulnerable,
with a green gate saying so every time.
The gate this board takes as its target keeps a configuration for this beside its
workflows rather than inside one:
gh api repos/Flowfin/jellyfin-plugin-sso/contents/.github --jq '.[].name'
CODEOWNERS
FUNDING.yml
ISSUE_TEMPLATE
actions
dependabot.yml
pull_request_template.md
workflows
and this repository keeps only workflows:
gh api repos/Flowfin/core/contents/.github --jq '.[].name'
workflows
That is why the parity table in #80 does not catch this. The table is built from
workflow files, and this is not one. It is the same class of gap and it belongs
on the board rather than in the space between two issues.
What this produces
A configuration that proposes updates on a stated cadence for every ecosystem
this repository actually has. Which those are is not known until the language
answer in #1 lands, with one exception that is true today: the workflow files
themselves are an ecosystem, they are pinned by digest, and a digest pin is the
one kind that cannot be updated by reading a version number.
Grouping that keeps the proposals readable. One pull request per package on a
weekly cadence is how review becomes a merge button, and a merge button is not
review.
The rule that an update proposal passes the same gate as any other change, with
no exemption for the check names in #15 through #19, because an update that
cannot pass the gate is information rather than an inconvenience.
A decided answer for a proposal nobody merges, so that the state of the queue in
six months is something that was chosen rather than something that happened.
Done when
The configuration exists, a deliberately stale pin produces a proposal, that
proposal runs the same checks as a pull request written by a person, and the
cadence, the grouping and the answer for an unmerged proposal are recorded
where the change is argued. Blocked on #11, #19, and #103, since a proposal
that adds a node to the graph has to meet the same rule as one a person adds.
#19 makes the resolved dependency graph reproducible and reddens a build on a
known vulnerability in it. Neither of those tells anybody that a dependency
moved. A lockfile nobody updates is reproducible right up to the day an advisory
lands against something inside it, and after that it is reproducibly vulnerable,
with a green gate saying so every time.
The gate this board takes as its target keeps a configuration for this beside its
workflows rather than inside one:
and this repository keeps only workflows:
That is why the parity table in #80 does not catch this. The table is built from
workflow files, and this is not one. It is the same class of gap and it belongs
on the board rather than in the space between two issues.
What this produces
A configuration that proposes updates on a stated cadence for every ecosystem
this repository actually has. Which those are is not known until the language
answer in #1 lands, with one exception that is true today: the workflow files
themselves are an ecosystem, they are pinned by digest, and a digest pin is the
one kind that cannot be updated by reading a version number.
Grouping that keeps the proposals readable. One pull request per package on a
weekly cadence is how review becomes a merge button, and a merge button is not
review.
The rule that an update proposal passes the same gate as any other change, with
no exemption for the check names in #15 through #19, because an update that
cannot pass the gate is information rather than an inconvenience.
A decided answer for a proposal nobody merges, so that the state of the queue in
six months is something that was chosen rather than something that happened.
Done when
The configuration exists, a deliberately stale pin produces a proposal, that
proposal runs the same checks as a pull request written by a person, and the
cadence, the grouping and the answer for an unmerged proposal are recorded
where the change is argued. Blocked on #11, #19, and #103, since a proposal
that adds a node to the graph has to meet the same rule as one a person adds.