Parking lot for ideas surfaced during the May 2026 cleanup pass. None of these are committed work — they only get done if a concrete use case shows up that needs them. Close this issue if/when it becomes stale.
Ideas
1. Group URLs by purpose in websites.yml
Today playbooks/files/websites.yml is a flat list. Splitting entries into commented sections (e.g. # Red Hat, # Azure, # Google, # Misc) would make it easier to reason about why each URL is in the list and spot omissions.
Trigger to actually do this: the list grows past ~25 entries, or someone asks "where does this URL come from?".
2. Add a tag field per entry + --limit-tags support
Let each entry carry one or more tags (azure, redhat, google, ...) and add a CLI-style filter so a user can probe only one provider's URLs:
ansible-playbook playbooks/main.yml -e 'limit_tags=azure'
Trigger to actually do this: someone wants to run a subset (e.g. only the Azure URLs against an Azure egress) and the full 16-entry run is too noisy.
3. Notification path beyond the auto-issue
The scheduled url-check.yml workflow currently surfaces failures as a GitHub issue. Could also notify via Slack/email/webhook for people who don't watch GitHub.
Trigger to actually do this: someone misses an auto-issue and an environment breaks because of it.
4. EXAMPLES.md or asciinema cast showing the failure path
The success path is self-explanatory from running the play. The failure path (per-URL line + non-zero exit) is the more interesting one. A cast or screenshot in docs would make it visible without needing to break a URL to see it.
Trigger to actually do this: if/when someone other than the author starts using the repo.
When any of these get picked up, open a fresh focused issue and close (or unlink) this one.
Parking lot for ideas surfaced during the May 2026 cleanup pass. None of these are committed work — they only get done if a concrete use case shows up that needs them. Close this issue if/when it becomes stale.
Ideas
1. Group URLs by purpose in
websites.ymlToday
playbooks/files/websites.ymlis a flat list. Splitting entries into commented sections (e.g.# Red Hat,# Azure,# Google,# Misc) would make it easier to reason about why each URL is in the list and spot omissions.Trigger to actually do this: the list grows past ~25 entries, or someone asks "where does this URL come from?".
2. Add a
tagfield per entry +--limit-tagssupportLet each entry carry one or more tags (
azure,redhat,google, ...) and add a CLI-style filter so a user can probe only one provider's URLs:ansible-playbook playbooks/main.yml -e 'limit_tags=azure'Trigger to actually do this: someone wants to run a subset (e.g. only the Azure URLs against an Azure egress) and the full 16-entry run is too noisy.
3. Notification path beyond the auto-issue
The scheduled
url-check.ymlworkflow currently surfaces failures as a GitHub issue. Could also notify via Slack/email/webhook for people who don't watch GitHub.Trigger to actually do this: someone misses an auto-issue and an environment breaks because of it.
4.
EXAMPLES.mdor asciinema cast showing the failure pathThe success path is self-explanatory from running the play. The failure path (per-URL line + non-zero exit) is the more interesting one. A cast or screenshot in docs would make it visible without needing to break a URL to see it.
Trigger to actually do this: if/when someone other than the author starts using the repo.
When any of these get picked up, open a fresh focused issue and close (or unlink) this one.