CI status watch by shodiBoy1 · Pull Request #2091 · devonfw/IDEasy

shodiBoy1 · 2026-06-29T21:13:55Z

This PR adds ci status watch and external discussion observer workflows

Implemented changes:

New ci-status-watch.yml weekday-morning workflow that lists the workflows currently red on main and 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).
Extended issue-pr-observer.yml the 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

Make sure the repo secret TEAMS_WEBHOOK_URL is set (Teams incoming webhook).
CI status watch: Actions -> "CI status watch" → Run workflow. If any workflow on main is red, a card with the list appears in Teams; otherwise the run log says all green and nothing is posted.
Issue/PR/Discussion observer: Actions -> "External Issue, PR & Discussion Observer" -> Run workflow. New external issues/PRs/discussions from the look-back window appear as two sections; if there's nothing new, no message is sent.
Check the run logs each step prints how many items it found.

Checklist for this PR

Make sure everything is checked before merging this PR. For further info please also see
our DoD.

When running mvn clean test locally all tests pass and build is successful
PR title is of the form #«issue-id»: «brief summary» (e.g. #921: fixed setup.bat). If no issue ID exists, title only.
PR top-level comment summarizes what has been done and contains link to addressed issue(s)
PR and issue(s) have suitable labels
Issue is set to In Progress and assigned to you or there is no issue (might happen for very small PRs)
You followed all coding conventions
You have added the issue implemented by your PR in CHANGELOG.adoc unless issue is labeled
with internal
You have formulated clear instructions on how to test your contribution under "Testing instructions"

coveralls · 2026-06-29T21:18:59Z

Coverage Report for CI Build 30564081540

Coverage increased (+0.03%) to 72.618%

Details

Coverage increased (+0.03%) from the base build.
Patch coverage: No coverable lines changed in this PR.
1 coverage regression across 1 file.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

1 previously-covered line in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	78.33%

Coverage Stats


Relevant Lines:	16997
Covered Lines:	12866
Line Coverage:	75.7%
Relevant Branches:	7603
Covered Branches:	4998
Branch Coverage:	65.74%
Branches in Coverage %:	Yes
Coverage Strength:	3.21 hits per line

💛 - Coveralls

…1/IDEasy into feature/ci-status-watch

quando632

Overall solid and defensively written. One point is worth resolving before merge (PR description vs. implementation), the rest are small follow-ups.

quando632 · 2026-07-14T08:19:42Z

+
+# 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


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.

Maybe it would be even smarter if we keep posting to our channel every night if something is broken so we get spammed and want to get rid of the spam by fixing the problem and nobody can excuse that he missed the notification ;)

quando632 · 2026-07-14T08:19:42Z

+              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


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.

@quando632 thanks for this finding that I agree to. 👍
Could you suggest a fix so we can merge?

Actually I was checking this again:

I do not see for which workflow we actually cancel in any normal situation so this would be relevant

If we simply send a notification whenever something is read, we can make this so much simpler and do not actually need to dig in the history at all.

I would therefore suggest to go for KISS and simply send the notification whenever the workflow is failed.

FYI:
Initially I thought we would simply integrate this directly into the according workflow what would be even simpler.
However, the advantage of this dedicated workflow is that this extra nice-to-have feature is isolated, not redundantly copied to multiple workflows, cannot break the critical workflows like nightly-build or especially release so I now like this approach...

Co-authored-by: quando632 <quang-hieu.do@capgemini.com> Co-authored-by: Jörg Hohwiller <hohwille@users.noreply.github.com>

quando632

@hohwille as requested, here is the concrete change for the KISS approach report whatever is currently red, every morning, instead of detecting a green→red transition. Four suggestions below, all in ci-status-watch.yml;

One thing worth deciding explicitly rather than leaving it as-is: you wrote "every night", but the cron is 0 7 * * 1-5. Something breaking on Friday evening stays silent until Monday 09:00 CEST. 0 7 * * * would close that gap weekday-only is defensible too, I just don't think it should stay that way by accident. Not included in the suggestions since it's your call.

hohwille · 2026-07-30T16:56:15Z

One thing worth deciding explicitly rather than leaving it as-is: you wrote "every night" ...

Thanks for pointing that out. Indeed I did not want to imply a workflow schedule/cron change as we do not work on weekends and need no notification on Saturday/Sunday. So I was just lax/un-precise and you are fully correct.

Co-authored-by: quando632 <quang-hieu.do@capgemini.com>

hohwille

@quando632 thanks for your constructive review suggestions following my KISS idea that I all applied 👍

I have one last suggestion, I would consider to apply before merge.
Can you quickly double-check that I am not missing something.
Then we finally merge and take this nice feature live.

hohwille · 2026-07-30T17:02:05Z

+          # long as it stays red it is reported every morning, so nobody can miss it.
+          RED=$(for WF_PATH in $WORKFLOWS; do
+              gh run list --repo "$REPO" --workflow "$WF_PATH" --branch "$BRANCH" \
+                --status completed --limit 5 --json conclusion,url,updatedAt,workflowName \


you increased the limit from 2 to 5. However, we only take the first result [0] and ignore the rest anyway.
IMHO the old limit was more reasonable (could be even 1).

Suggested change

--status completed --limit 5 --json conclusion,url,updatedAt,workflowName \

--status completed --limit 2 --json conclusion,url,updatedAt,workflowName \

shodiBoy1 added 2 commits June 29, 2026 23:02

CI status watch and external discussion observer workflows

18f2678

CI status watch and external discussion observer workflows

d27c73a

github-project-automation Bot added this to IDEasy board Jun 29, 2026

github-project-automation Bot moved this to 🆕 New in IDEasy board Jun 29, 2026

shodiBoy1 self-assigned this Jun 29, 2026

shodiBoy1 added SCM software-configuration-management (github actions, internal processes, git or github utilization) internal Nothing to be added to CHANGELOG, only internal story workflow GitHub actions (CI,CD,update urls/CVEs) labels Jun 29, 2026

Merge branch 'main' into feature/ci-status-watch

862b485

shodiBoy1 marked this pull request as ready for review June 29, 2026 21:27

shodiBoy1 moved this from 🆕 New to Team Review in IDEasy board Jun 29, 2026

shodiBoy1 and others added 6 commits June 30, 2026 09:03

CI status watch

60bfafb

Merge branch 'feature/ci-status-watch' of https://github.com/shodiBoy…

70434a8

…1/IDEasy into feature/ci-status-watch

CI status watch

0d36b2d

filter observer by daily team list instead of quthor association

a613459

Merge branch 'main' into feature/ci-status-watch

f05d69d

Update issue-pr-observer.yml

163bc41

hohwille assigned quando632 Jul 6, 2026

Merge branch 'main' into feature/ci-status-watch

980739c

quando632 reviewed Jul 14, 2026

View reviewed changes

hohwille moved this from Team Review to 👀 In review in IDEasy board Jul 27, 2026

hohwille reviewed Jul 27, 2026

View reviewed changes

Comment thread .github/workflows/ci-status-watch.yml Outdated

Apply suggestions from code review

a9080ce

Co-authored-by: quando632 <quang-hieu.do@capgemini.com> Co-authored-by: Jörg Hohwiller <hohwille@users.noreply.github.com>

hohwille changed the title ~~Feature/ci status watch~~ CI status watch Jul 27, 2026

quando632 reviewed Jul 29, 2026

View reviewed changes

Comment thread .github/workflows/ci-status-watch.yml Outdated

Comment thread .github/workflows/ci-status-watch.yml Outdated

Comment thread .github/workflows/ci-status-watch.yml Outdated

Comment thread .github/workflows/ci-status-watch.yml Outdated

Apply suggestions from code review

67999a2

Co-authored-by: quando632 <quang-hieu.do@capgemini.com>

hohwille approved these changes Jul 30, 2026

View reviewed changes

Merge branch 'main' into feature/ci-status-watch

ce0c647

	--status completed --limit 5 --json conclusion,url,updatedAt,workflowName \
	--status completed --limit 2 --json conclusion,url,updatedAt,workflowName \

Uh oh!

Conversation

shodiBoy1 commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

This PR adds ci status watch and external discussion observer workflows

Implemented changes:

Testing instructions

Checklist for this PR

Uh oh!

coveralls commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Coverage Report for CI Build 30564081540

Coverage increased (+0.03%) to 72.618%

Details

Uncovered Changes

Coverage Regressions

Coverage Stats

💛 - Coveralls

Uh oh!

quando632 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quando632 Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

hohwille Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

quando632 Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

hohwille Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

hohwille Jul 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

quando632 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hohwille commented Jul 30, 2026

Uh oh!

hohwille left a comment

Choose a reason for hiding this comment

Uh oh!

hohwille Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

shodiBoy1 commented Jun 29, 2026 •

edited

Loading

coveralls commented Jun 29, 2026 •

edited

Loading

quando632 left a comment •

edited

Loading

quando632 left a comment •

edited

Loading