Sweep-key: .github/workflows/freshness.yml failure
.github/workflows/freshness.yml runs on a schedule, and its last run on the default branch ended in failure.
A scheduled run has nobody in front of it at the time it runs, so this is raised here rather than left in a tab.
The runs that reached failure
What closes this
A later run of .github/workflows/freshness.yml that
- ran on its schedule rather than being dispatched by hand, because a run somebody asked for has somebody in front of it and clears nothing here
- is a run of the default branch, which is the branch a scheduled run runs
- has ended, and ended in success
and whatever change made it do so. Nothing else clears the key. Dispatching this workflow by hand and watching it go green does not: the newest scheduled run is still the one above, so the next sweep raises this again under the same key.
That is also what a re-raise means if the workflow really is still failing, which is the behaviour rather than a defect.
The line at the top is how a later sweep recognises this issue. Removing it makes the next failure raise a second issue.
Sweep-key: .github/workflows/freshness.yml failure
.github/workflows/freshness.ymlruns on a schedule, and its last run on the default branch ended in failure.A scheduled run has nobody in front of it at the time it runs, so this is raised here rather than left in a tab.
The runs that reached failure
What closes this
A later run of
.github/workflows/freshness.ymlthatand whatever change made it do so. Nothing else clears the key. Dispatching this workflow by hand and watching it go green does not: the newest scheduled run is still the one above, so the next sweep raises this again under the same key.
That is also what a re-raise means if the workflow really is still failing, which is the behaviour rather than a defect.
The line at the top is how a later sweep recognises this issue. Removing it makes the next failure raise a second issue.