Skip to content

Set PR Roadmap from target branch when merged - #59

Open
YanxuanLiu wants to merge 5 commits into
mainfrom
auto-roadmap-from-pom
Open

Set PR Roadmap from target branch when merged#59
YanxuanLiu wants to merge 5 commits into
mainfrom
auto-roadmap-from-pom

Conversation

@YanxuanLiu

@YanxuanLiu YanxuanLiu commented Aug 13, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • preserve the existing behavior that adds issues and pull requests to the configured GitHub Project
  • for merged pull requests in NVIDIA/cudf-spark and NVIDIA/cudf-spark-jni, read the root pom.xml at the event's immutable merged-result SHA and derive the YY.MM release
  • set the Project Roadmap field only when it is empty, preserving existing values and re-checking immediately before the update
  • report missing or ambiguous POM versions and Roadmap options without assigning a value

Why

Roadmap should reflect the release branch at merge time. A pull request that stays open across release cycles is therefore assigned from the branch state it actually merges into, rather than from its state when opened.

Consumer workflow updates add the merged closed event while continuing to add issues and pull requests on opened:

Validation

  • Python 3.9 and 3.14 syntax checks
  • 14 focused tests covering add-only behavior for opened/unmerged events, both target repositories on merge, existing values and the final pre-update re-check, merged-result SHA POM reads, malformed or ambiguous versions, and missing or duplicate options
  • git diff --check

Signed-off-by: YanxuanLiu <yanxuanl@nvidia.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR replaces the previous actions/github-script implementation of the add-to-project composite action with a Python-based implementation that can optionally derive and set the GitHub Project “Roadmap” field for PRs in NVIDIA/cudf-spark and NVIDIA/cudf-spark-jni by reading the target branch root pom.xml at the immutable base SHA.

Changes:

  • Replaced the composite action step from actions/github-script@v8 to a Python runner invoking add_to_project.py.
  • Added add_to_project.py to (1) add issues/PRs to the configured GitHub Project and (2) auto-populate “Roadmap” from the target branch pom.xml for the specified repositories, only when the field is currently empty.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
add-to-project/add_to_project.py New standard-library GitHub REST/GraphQL client and Roadmap auto-population logic based on target-branch pom.xml.
add-to-project/action.yml Switches the composite action implementation from github-script to running the new Python script with the provided token.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread add-to-project/action.yml
Comment thread add-to-project/add_to_project.py
@greptile-apps

greptile-apps Bot commented Aug 13, 2026

Copy link
Copy Markdown

Greptile Summary

The PR replaces the JavaScript-based composite-action implementation with a Python GitHub API client that preserves project membership and derives merged pull requests’ Roadmap values from the target branch POM.

  • Adds robust REST and GraphQL response validation and project-item lookup.
  • Reads and validates the root POM at the merged-result SHA for supported repositories.
  • Preserves existing Roadmap values and refreshes the field immediately before updating it.
  • Updates the action’s token requirements and invokes the new Python entry point.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
add-to-project/action.yml Replaces actions/github-script with the Python implementation and exposes the token through GH_TOKEN.
add-to-project/add_to_project.py Implements project-item management, merged-result POM parsing, release-option resolution, and best-effort Roadmap preservation.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[GitHub event] --> B[Load issue or pull request]
  B --> C[Find configured Project V2]
  C --> D{Item already in project?}
  D -- No --> E[Add project item]
  D -- Yes --> F[Reuse existing item]
  E --> G{Merged PR in supported repository?}
  F --> G
  G -- No --> H[Finish]
  G -- Yes --> I{Roadmap already set?}
  I -- Yes --> H
  I -- No --> J[Read root POM at merge-result SHA]
  J --> K[Derive YY.MM and resolve option]
  K --> L[Refresh Roadmap]
  L --> M{Still empty?}
  M -- No --> H
  M -- Yes --> N[Set Roadmap option]
  N --> H
Loading

Reviews (6): Last reviewed commit: "Keep Roadmap fix minimal" | Re-trigger Greptile

Comment thread add-to-project/add_to_project.py
Comment thread add-to-project/add_to_project.py
Comment thread add-to-project/add_to_project.py Outdated
return base_ref, base_sha, pom_xml


def populate_roadmap(client, repository, pull_request, project, item):

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The function body never references pull_request, can it be removed?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, removed.

Signed-off-by: YanxuanLiu <yanxuanl@nvidia.com>
@NvTimLiu

Copy link
Copy Markdown

One more concern: the “add to project” workflow runs only on GitHub’s [open] event.

This is currently sufficient for spark-rapids, because project membership does not need to change between release cycles.

However, if a PR remains open from 26.10 until 27.10, the Roadmap should be determined when the PR is merged. In that case, it should be set to 27.10, not 26.10.

Ideally, the Roadmap should be set by the GitHub Actions workflow when the PR is merged.

@YanxuanLiu

Copy link
Copy Markdown
Collaborator Author

One more concern: the “add to project” workflow runs only on GitHub’s [open] event.

This is currently sufficient for spark-rapids, because project membership does not need to change between release cycles.

However, if a PR remains open from 26.10 until 27.10, the Roadmap should be determined when the PR is merged. In that case, it should be set to 27.10, not 26.10.

Ideally, the Roadmap should be set by the GitHub Actions workflow when the PR is merged.

Thanks, that makes sense. I propose keeping opened only for adding the PR to the Project, then setting Roadmap on closed only when the PR was merged.
At merge time, if Roadmap is empty, derive it from the target branch POM. If it was already set manually or by another automation, preserve it. Does that match the expected behavior?

@NvTimLiu

Copy link
Copy Markdown

One more concern: the “add to project” workflow runs only on GitHub’s [open] event.
This is currently sufficient for spark-rapids, because project membership does not need to change between release cycles.
However, if a PR remains open from 26.10 until 27.10, the Roadmap should be determined when the PR is merged. In that case, it should be set to 27.10, not 26.10.
Ideally, the Roadmap should be set by the GitHub Actions workflow when the PR is merged.

Thanks, that makes sense. I propose keeping opened only for adding the PR to the Project, then setting Roadmap on closed only when the PR was merged. At merge time, if Roadmap is empty, derive it from the target branch POM. If it was already set manually or by another automation, preserve it. Does that match the expected behavior?

Make sense

Signed-off-by: YanxuanLiu <yanxuanl@nvidia.com>
@YanxuanLiu YanxuanLiu changed the title Auto-set PR Roadmap from target branch pom.xml Set PR Roadmap from target branch when merged Aug 14, 2026
Signed-off-by: YanxuanLiu <yanxuanl@nvidia.com>
Signed-off-by: YanxuanLiu <yanxuanl@nvidia.com>
@greptile-apps

greptile-apps Bot commented Aug 14, 2026

Copy link
Copy Markdown

Want your agent to iterate on Greptile's feedback? Try greploops.

@YanxuanLiu
YanxuanLiu marked this pull request as draft August 14, 2026 08:32
@YanxuanLiu
YanxuanLiu marked this pull request as ready for review August 14, 2026 09:57
@YanxuanLiu

Copy link
Copy Markdown
Collaborator Author

One more concern: the “add to project” workflow runs only on GitHub’s [open] event.
This is currently sufficient for spark-rapids, because project membership does not need to change between release cycles.
However, if a PR remains open from 26.10 until 27.10, the Roadmap should be determined when the PR is merged. In that case, it should be set to 27.10, not 26.10.
Ideally, the Roadmap should be set by the GitHub Actions workflow when the PR is merged.

Thanks, that makes sense. I propose keeping opened only for adding the PR to the Project, then setting Roadmap on closed only when the PR was merged. At merge time, if Roadmap is empty, derive it from the target branch POM. If it was already set manually or by another automation, preserve it. Does that match the expected behavior?

Make sense

Updated and tested in my personal repo for both opened and closed behaviours

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants