The canary is checked on a schedule
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 64/100
Research direction
Read scripts/canary.py and the canary tooling in issue #322 to understand the plant and check commands; the scheduled workflow must wait until that tooling reaches main. Then add a scheduled workflow that renews the branch, waits for checks, runs the check, and opens an issue when it names a failed check. Done when a switched-off check makes the run fail and opens an issue without manual steps; explain each token permission in the pull request.
Written by the indexing model from the issue text.
Description
What needs doing
The canary (#322) is renewed and checked by hand, once a week. A
scheduled workflow should do the check: find the open canary pull
request, run scripts/canary.py check, and turn its run red when a
check that must be red is not, when the canary is stale, or when the
check could not judge.
The workflow only reads. It needs no token of its own, pushes nothing
and opens no issue: the red run and its summary are the report. Say in
the pull request why each permission is needed. The renewal of the
canary branch from dev (scripts/canary.py plant) stays a weekly
step by hand.
A scheduled workflow runs from the default branch, so the schedule
starts when main has the workflow file.
Why
A check that someone must remember to run by hand is skipped sooner
or later, and then a required check can stop checking without anyone
noticing.
Done when
- A check that is switched off turns the scheduled run red, with
no step by hand.
Blocked by: the workflow file on main.
- Dominant language
- Python
- Stars
- 2.1k
- Forks
- 197
- Avg merge
- 9h 50m
- Merged PRs (30d)
- 325
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from inferstep/ATLAS
-
Bootstrap: the last two steps run as the user who owns the installMay be free again @assassinationss claimed this 21 days ago, and no pull request is open. Openarea/install reliability
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
inferstep/ATLAS#412 · 4 comments ·
Maintainers usually reply within 1 day
-
area/cli
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
area/cli area/lens status/ready
Difficulty 2/5 Half a day Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
area/ci status/ready
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
inferstep/ATLAS#245 · 4 comments ·
Maintainers usually reply within 1 day
-
area/proxy reliability
Difficulty 4/5 3-5 days Newbie friendliness 56/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
developmentseed/titiler-cmr#278 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days