CI status watch

[shodiBoy1]

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

1. Make sure the repo secret TEAMS_WEBHOOK_URL is set (Teams incoming webhook).
2. 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.
3. 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.
4. 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]

Coverage Report for CI Build 33818955797

Coverage increased (+0.02%) to 73.823%

Details

• Coverage increased (+0.02%) 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/version/VersionSegment.java	1	91.86%

---

Coverage Stats

Relevant Lines:	18583
Covered Lines:	14335
Line Coverage:	77.14%
Relevant Branches:	8276
Covered Branches:	5493
Branch Coverage:	66.37%
Branches in Coverage %:	Yes
Coverage Strength:	3.29 hits per line

---

💛 - Coveralls

[quando632]

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

[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]

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.

[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]

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 \

[quando632]

The [0] does not act on the API result but on the filtered array: [ .[] | select(...) ][0] first drops cancelled/skipped runs, then takes the newest of what is left. So --limit controls how far we can look past a streak of cancelled runs, not how many results we use. With --limit 1 a single cancelled run on top hides whatever sits underneath.

Real streaks on main: nightly-build 3 in a row (16 to 18 Dec 2025), integration-tests 4 in a row (9 to 17 Dec 2025). With --limit 2 a red run below either of them would be reported as not red. I chose 5 because it covers the longest streak we have actually seen.

It is also free: gh run list issues the same 2 API requests for --limit 2 and --limit 5.

That it reads the other way means the line needs a comment. A suggestion in this thread would only replace this line, so I put it on the comment block above (lines 39 to 42) as a separate comment.

[quando632]

Follow-up to the --limit thread: documenting why the limit is what it is, so the next reader does not read it as dead weight either.

Suggested change

	# A workflow counts as red if its newest completed run that produced a real result
	# failed; cancelled/skipped runs say nothing about the code and are ignored. This is
	# exactly what the README badge shows. There is no look-back window on purpose: as
	# long as it stays red it is reported every morning, so nobody can miss it.
	# A workflow counts as red if its newest completed run that produced a real result
	# failed; cancelled/skipped runs say nothing about the code and are ignored. This is
	# exactly what the README badge shows. There is no look-back window on purpose: as
	# long as it stays red it is reported every morning, so nobody can miss it.
	# The limit is not about how many runs we evaluate, that is always one. It defines how
	# far we can look past a streak of cancelled runs; 5 covers the longest streak seen (4).

[hohwille]

@shodiBoy1 thanks for your PR. Great that you could automate this and improve the observer. 👍
I only have a small suggestion. As a quickfix we can update the hardcoded list.
Please also create a new issue that we should create a self-maintained replacement of this hard-coded list. Then we can finally merge. Sorry for the long review delay.

[hohwille]

This will be hard to maintain as our team is so volatile.
Would it be possible somehow to get this from the GitHub IDE Group membership or from the board somehow?
For the moment we can also merge with a hard-coded list. Maybe you can update it before I merge.
vivu001. tineff96, areinicke, AdemZarrouki, KarimALofty Caylipp, marceltchanga9, and Paras14 already left.
There are several new members meanwhile.

[shodiBoy1]

i agree, a hardcoded list would be difficult to maintain with a frquently changing team. So i implemented the dynamic option. The workflow gets the Github teams linked to project/5 and uses their current membership. New and departed members are handled automatically.

We only need to link the official IDE team to project/5 if this has not already been done and configure the repo secret 'TEAM_TOKEN' with projects:read and members:read. If the lookup or another API call fails, the workflow fails instead of posting incomplete results. The next run resumes from the last successful run, so no activity is missed.