Casually9790andClaude Opus 5.5
e00f40eaf4
ctf_status.py is now just the command line; the work lives in tracker/. The rules that decide whether a challenge is believed are in tracker/checks.py, one function per rule, listed in README_CHECKS and REPO_CHECKS. Output is unchanged. Read the config from .env only (ctf_status.env.example -> .env.example), let single_run_lock() hold its own lock files, and rewrite the README as a short overview of what the repo does and how to run it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
14 lines
675 B
Python
14 lines
675 B
Python
"""The pieces behind ctf_status.py, in the order the data flows through them:
|
|
|
|
config.py read .env and the environment
|
|
gitlab.py list the group's repos, download README.md and description.yml
|
|
challenge.py turn a README header into a Challenge (status, category, ...)
|
|
checks.py decide what is wrong with a challenge, and whether to believe
|
|
a Testing Ready+ status <- the rules live here
|
|
overview.py run all of the above over every repo, group and sort the result
|
|
terminal.py the terminal summary
|
|
markdown.py the HedgeDoc note
|
|
challs.py challs.txt for the deployment repo
|
|
hedgedoc.py write the note into HedgeDoc
|
|
"""
|