Feature/ci status watch#2091
Conversation
shodiBoy1
added
SCM
Coverage Report for CI Build 28817579077Coverage increased (+0.01%) to 71.811%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions1 previously-covered line in 1 file lost coverage.
Coverage Stats
💛 - Coveralls |
…1/IDEasy into feature/ci-status-watch
|
|
||
| # Posts a Teams message ONLY when one of the README badge workflows on the default | ||
| # branch turns red (green -> red). For each it compares the two latest runs with gh; a | ||
| # change is reported only if the newest run finished within the look-back window, so a |
There was a problem hiding this comment.
The PR description says the workflow lists the currently red workflows and keeps them listed until they turn green again. This header comment and the code actually implement a green-to-red transition that is deduplicated (a workflow that stays red is reported once, not every day). The comment here is the accurate one, so please update the PR description to match the implementation.
| GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| WEBHOOK: ${{ secrets.TEAMS_WEBHOOK_URL }} | ||
| REPO: ${{ github.repository }} | ||
| BRANCH: ${{ github.event.repository.default_branch }} |
There was a problem hiding this comment.
github.event.repository.default_branch is not guaranteed to be populated on the schedule event payload. If it is empty, gh run list --branch "" silently widens the query to all branches. github.ref_name resolves to the default branch on a scheduled run and is always set.
| BRANCH: ${{ github.event.repository.default_branch }} | |
| BRANCH: ${{ github.ref_name }} |
| else | ||
| SINCE=$(date -u -d '1 day ago' +%Y-%m-%dT%H:%M:%SZ) | ||
| fi | ||
| echo "Checking badge workflows for red since $SINCE" |
There was a problem hiding this comment.
The branch drives the whole query but is never logged, which makes a failing scheduled run harder to debug. Suggest logging the resolved branch.
| echo "Checking badge workflows for red since $SINCE" | |
| echo "Checking badge workflows for red since $SINCE" | |
| echo "Resolved branch: $BRANCH" |
| [ -z "$ROW" ] && continue | ||
| IFS=$'\t' read -r CUR CURTIME URL PREV NAME <<< "$ROW" | ||
| [ -z "$CUR" ] && continue | ||
| [[ "$CURTIME" > "$SINCE" ]] || continue |
There was a problem hiding this comment.
this is a lexicographic string comparison, not a date comparison. It is correct here only because both values are fixed-format ISO-8601 UTC (ending in Z). Worth a short inline comment so it is not later refactored into something that breaks that assumption.
| IFS=$'\t' read -r CUR CURTIME URL PREV NAME <<< "$ROW" | ||
| [ -z "$CUR" ] && continue | ||
| [[ "$CURTIME" > "$SINCE" ]] || continue | ||
| if is_red "$CUR" && { [ "$PREV" = "success" ] || [ -z "$PREV" ]; }; then |
There was a problem hiding this comment.
A genuinely red run is swallowed when the previous run was cancelled: for runs [failure, cancelled], PREV is cancelled, which is neither success nor empty, so nothing is reported. Since cancelled runs are pruned daily the window is small, but within the same day a real failure can be hidden. Consider treating cancelled as neither red nor green and comparing against the next older non-cancelled run.
| vivu001 | ||
| run: | | ||
| # so a failing gh api trips the || fallback instead of being hidden by the trailing jq | ||
| set -o pipefail |
There was a problem hiding this comment.
This intentionally uses only set -o pipefail and not set -e, because the per-source || { ... ITEMS='[]'; } fallbacks rely on the script continuing after a failed fetch. Please document that intent inline so it is not later "hardened" to set -e, which would break the fallbacks.
| set -o pipefail | |
| set -o pipefail # no `set -e`: the per-source `|| { ... ITEMS='[]'; }` fallbacks must keep the script running |
4 participants
This PR adds ci status watch and external discussion observer workflows
Implemented changes:
ci-status-watch.ymlweekday-morning workflow that lists the workflows currently red onmainand posts them as a single Teams card, so a broken CI is noticed in the Daily. Reports current state (a workflow stays listed until it's green again); creates no issues. Read-only (actions: read).issue-pr-observer.ymlthe daily digest now also reports new external GitHub Discussions (fetched via GraphQL, since they have no REST search). Issues/PRs and discussions are shown as two separate sections in the same card. Each source falls back to empty on error, so a failure in one still posts the other.Testing instructions
TEAMS_WEBHOOK_URLis set (Teams incoming webhook).mainis red, a card with the list appears in Teams; otherwise the run log says all green and nothing is posted.Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.bat). If no issue ID exists, title only.In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internal