test: dummy PR for CI-pending tracking validation - #20
Open
pahud wants to merge 2 commits into
Open
Conversation
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
This test PR correctly adds a marker file for CI-pending tracking validation. No blocking issues identified.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
This was referenced Jul 16, 2026
mergify Bot
pushed a commit
to aws/aws-cdk
that referenced
this pull request
Jul 20, 2026
…CI approval (#38220) ### Issue Closes #38196 ### Reason for this change There are 100+ open PRs from beginning contributors waiting for maintainer action. Many have been waiting weeks with no CI feedback. There is no dashboard or alert for this backlog. ### Description of changes Adds a daily scheduled GitHub Actions workflow (`pending-maintainer-action-check.yml`) that: 1. Fetches open PRs with the `beginning-contributor` label (paginated, so it scales past 100 PRs) 2. For each non-draft PR, checks whether it needs maintainer CI action: - **Pending approval** — a workflow run for the PR's head commit has conclusion `action_required`; a maintainer needs to click Approve - **No build CI activity** — no build workflow run (matched by workflow file path) and no commit statuses on the head commit; CI approval was skipped or never triggered, even if non-build `pull_request_target` workflows (PR Linter, prioritization, etc.) ran 3. Creates (or updates) a **weekly tracking issue** listing all pending PRs. The issue is identified by the `ci-pending-tracking` marker label plus a week key in the title — the ISO week number combined with the date of the Monday that week starts on (e.g. `CI pending maintainer action: week 2026-July13-W29`) — no hardcoded issue number. First run of the week creates the issue; subsequent daily runs update its body in place. **Update from the previous revision** (per [review feedback](#38220 (comment))): the project-board approach has been reverted back to issue-based tracking, but with a weekly issue keyed by marker label + week key instead of a single hardcoded issue. The speculative `build_completed_no_status` detection branch has been dropped — it never corresponded to an observed real scenario; we can revisit if stuck pipelines are actually seen. **Update from the latest review round**: the workflow is now upstream-only (plain `github.repository == 'aws/aws-cdk'` guard, `PROJEN_GITHUB_TOKEN` only — no `GITHUB_TOKEN` fallback), matching the other project-prioritization workflows; and the no-CI-activity check is scoped to the absence of a *build* workflow run rather than all runs, so PRs whose build never started aren't masked by `pull_request_target` workflow runs (e.g. #37984). Design notes: - The week key includes the week's start date (`2026-July13-W29`) so maintainers can see at a glance which calendar week an issue covers without decoding ISO week numbers - The issue body is a Markdown table (PR link, title, author, pending-since date) with a per-reason summary line. PR titles are sanitized before embedding in table cells (pipes escaped, whitespace collapsed) — addressing the title-sanitization concern from earlier review - Issues from previous weeks are left open for maintainers to review and close manually; each new week gets a fresh issue - If no PRs are pending and no issue exists for the current week, nothing is created (no noise) - The workflow runs only in `aws/aws-cdk` (same guard and single-token pattern as the other project-prioritization workflows); `owner`/`repo` still come from the Actions `context` rather than being hardcoded - Supports a `dry_run` input on manual dispatch to log intended issue writes without performing them ``` ┌────────────────────────────────────────────────────────────────┐ │ pending-maintainer-action-check.yml │ │ Daily at 08:00 UTC or manual dispatch (dry_run opt-in) │ │ (upstream repo only) │ └──────────────────────────┬─────────────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────────────┐ │ List open 'beginning-contributor' PRs (paginated) │ └──────────────────────────┬─────────────────────────────────────┘ ▼ ┌───────────────────────┐ │ For each PR: │ │ - skip drafts │ │ - get workflow runs │ │ for head SHA │ └───────────┬───────────┘ │ ┌─────────────┴─────────────┐ ▼ ▼ ┌──────────────────┐ ┌──────────────────────┐ │ Any run has │ │ No build workflow │ │ conclusion: │ │ run AND zero commit │ │ action_required? │ │ statuses? │ └────────┬─────────┘ └──────────┬───────────┘ │ pending_approval │ no_ci_activity └─────────────┬──────────────┘ ▼ ┌────────────────────────────────────────────────────────────────┐ │ Weekly tracking issue (label: ci-pending-tracking) │ │ │ │ "CI pending maintainer action: week 2026-July13-W29" │ │ - exists for this week? → update body in place │ │ - doesn't exist? → create it │ │ - nothing pending, none exists → do nothing │ └────────────────────────────────────────────────────────────────┘ ``` ### 🔍 For reviewer: notes before merge - [ ] The `ci-pending-tracking` label does not exist in `aws/aws-cdk` yet. `issues.create` with a nonexistent label creates it automatically when the token has push access, but creating it up front (with a description/color) is cleaner. - [ ] Previous weeks' issues are intentionally left open for a human to close after review. If you'd prefer the workflow to auto-close the prior week's issue when creating a new one, that's a small follow-up. ### Description of how you validated changes Validated end-to-end in the [`pahud/aws-cdk`](https://github.com/pahud/aws-cdk) fork before updating this PR. (An earlier revision allowed `workflow_dispatch` in forks for this purpose; the final workflow is upstream-only per review.) **PoC / live-data preview**: [pahud#21](pahud#21) shows the exact production output — the unmodified script run against real `aws/aws-cdk` PR data (69 pending PRs detected as of the latest run), with only the issue write redirected to the fork. The issue title demonstrates the week-key format: `CI pending maintainer action: week 2026-July13-W29`. Fork validation details: - Set up a test PR ([pahud#20](pahud#20)) labeled `beginning-contributor` with no workflow runs and no commit statuses on its head commit (the `no_ci_activity` state) - **First dispatch**: correctly detected the PR (`PR #20: needs attention (no_ci_activity)`) and created a tracking issue labeled `ci-pending-tracking`, listing the PR with author and reason - **Second dispatch**: found the existing week's issue via the marker label + week key and updated its body in place — exactly one open `ci-pending-tracking` issue after both runs (no duplicates) - Week key logic unit-checked locally, including boundary cases: `2026-07-13 → 2026-July13-W29`, `2026-07-19 → 2026-July13-W29` (same week), `2026-07-20 → 2026-July20-W30` (Monday rollover), and year boundaries (`2026-01-01 → 2025-December29-W01`, `2027-01-03 → 2026-December28-W53`) — the year prefix uses the Monday's calendar year so the date part always reads as a real date - The build-scoped detection (latest revision) verified against mocked workflow-run scenarios: `action_required` run → `pending_approval`; non-build runs only (the #37984 shape) → `no_ci_activity`; completed build run → ok; zero runs → `no_ci_activity` ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)
ali-n4i
pushed a commit
to ali-n4i/aws-cdk
that referenced
this pull request
Jul 29, 2026
…CI approval (aws#38220) ### Issue Closes aws#38196 ### Reason for this change There are 100+ open PRs from beginning contributors waiting for maintainer action. Many have been waiting weeks with no CI feedback. There is no dashboard or alert for this backlog. ### Description of changes Adds a daily scheduled GitHub Actions workflow (`pending-maintainer-action-check.yml`) that: 1. Fetches open PRs with the `beginning-contributor` label (paginated, so it scales past 100 PRs) 2. For each non-draft PR, checks whether it needs maintainer CI action: - **Pending approval** — a workflow run for the PR's head commit has conclusion `action_required`; a maintainer needs to click Approve - **No build CI activity** — no build workflow run (matched by workflow file path) and no commit statuses on the head commit; CI approval was skipped or never triggered, even if non-build `pull_request_target` workflows (PR Linter, prioritization, etc.) ran 3. Creates (or updates) a **weekly tracking issue** listing all pending PRs. The issue is identified by the `ci-pending-tracking` marker label plus a week key in the title — the ISO week number combined with the date of the Monday that week starts on (e.g. `CI pending maintainer action: week 2026-July13-W29`) — no hardcoded issue number. First run of the week creates the issue; subsequent daily runs update its body in place. **Update from the previous revision** (per [review feedback](aws#38220 (comment))): the project-board approach has been reverted back to issue-based tracking, but with a weekly issue keyed by marker label + week key instead of a single hardcoded issue. The speculative `build_completed_no_status` detection branch has been dropped — it never corresponded to an observed real scenario; we can revisit if stuck pipelines are actually seen. **Update from the latest review round**: the workflow is now upstream-only (plain `github.repository == 'aws/aws-cdk'` guard, `PROJEN_GITHUB_TOKEN` only — no `GITHUB_TOKEN` fallback), matching the other project-prioritization workflows; and the no-CI-activity check is scoped to the absence of a *build* workflow run rather than all runs, so PRs whose build never started aren't masked by `pull_request_target` workflow runs (e.g. aws#37984). Design notes: - The week key includes the week's start date (`2026-July13-W29`) so maintainers can see at a glance which calendar week an issue covers without decoding ISO week numbers - The issue body is a Markdown table (PR link, title, author, pending-since date) with a per-reason summary line. PR titles are sanitized before embedding in table cells (pipes escaped, whitespace collapsed) — addressing the title-sanitization concern from earlier review - Issues from previous weeks are left open for maintainers to review and close manually; each new week gets a fresh issue - If no PRs are pending and no issue exists for the current week, nothing is created (no noise) - The workflow runs only in `aws/aws-cdk` (same guard and single-token pattern as the other project-prioritization workflows); `owner`/`repo` still come from the Actions `context` rather than being hardcoded - Supports a `dry_run` input on manual dispatch to log intended issue writes without performing them ``` ┌────────────────────────────────────────────────────────────────┐ │ pending-maintainer-action-check.yml │ │ Daily at 08:00 UTC or manual dispatch (dry_run opt-in) │ │ (upstream repo only) │ └──────────────────────────┬─────────────────────────────────────┘ ▼ ┌────────────────────────────────────────────────────────────────┐ │ List open 'beginning-contributor' PRs (paginated) │ └──────────────────────────┬─────────────────────────────────────┘ ▼ ┌───────────────────────┐ │ For each PR: │ │ - skip drafts │ │ - get workflow runs │ │ for head SHA │ └───────────┬───────────┘ │ ┌─────────────┴─────────────┐ ▼ ▼ ┌──────────────────┐ ┌──────────────────────┐ │ Any run has │ │ No build workflow │ │ conclusion: │ │ run AND zero commit │ │ action_required? │ │ statuses? │ └────────┬─────────┘ └──────────┬───────────┘ │ pending_approval │ no_ci_activity └─────────────┬──────────────┘ ▼ ┌────────────────────────────────────────────────────────────────┐ │ Weekly tracking issue (label: ci-pending-tracking) │ │ │ │ "CI pending maintainer action: week 2026-July13-W29" │ │ - exists for this week? → update body in place │ │ - doesn't exist? → create it │ │ - nothing pending, none exists → do nothing │ └────────────────────────────────────────────────────────────────┘ ``` ### 🔍 For reviewer: notes before merge - [ ] The `ci-pending-tracking` label does not exist in `aws/aws-cdk` yet. `issues.create` with a nonexistent label creates it automatically when the token has push access, but creating it up front (with a description/color) is cleaner. - [ ] Previous weeks' issues are intentionally left open for a human to close after review. If you'd prefer the workflow to auto-close the prior week's issue when creating a new one, that's a small follow-up. ### Description of how you validated changes Validated end-to-end in the [`pahud/aws-cdk`](https://github.com/pahud/aws-cdk) fork before updating this PR. (An earlier revision allowed `workflow_dispatch` in forks for this purpose; the final workflow is upstream-only per review.) **PoC / live-data preview**: [pahud#21](pahud#21) shows the exact production output — the unmodified script run against real `aws/aws-cdk` PR data (69 pending PRs detected as of the latest run), with only the issue write redirected to the fork. The issue title demonstrates the week-key format: `CI pending maintainer action: week 2026-July13-W29`. Fork validation details: - Set up a test PR ([pahud#20](pahud#20)) labeled `beginning-contributor` with no workflow runs and no commit statuses on its head commit (the `no_ci_activity` state) - **First dispatch**: correctly detected the PR (`PR aws#20: needs attention (no_ci_activity)`) and created a tracking issue labeled `ci-pending-tracking`, listing the PR with author and reason - **Second dispatch**: found the existing week's issue via the marker label + week key and updated its body in place — exactly one open `ci-pending-tracking` issue after both runs (no duplicates) - Week key logic unit-checked locally, including boundary cases: `2026-07-13 → 2026-July13-W29`, `2026-07-19 → 2026-July13-W29` (same week), `2026-07-20 → 2026-July20-W30` (Monday rollover), and year boundaries (`2026-01-01 → 2025-December29-W01`, `2027-01-03 → 2026-December28-W53`) — the year prefix uses the Monday's calendar year so the date part always reads as a real date - The build-scoped detection (latest revision) verified against mocked workflow-run scenarios: `action_required` run → `pending_approval`; non-build runs only (the aws#37984 shape) → `no_ci_activity`; completed build run → ok; zero runs → `no_ci_activity` ### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Test PR to validate the pending-maintainer-action workflow. Safe to close.