ci: 👷 Add workflow to automatically open upstream PRs on merge #15
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR adds a GitHub Actions workflow that automatically creates pull requests in the upstream material-components/material-web repository when PRs are merged into the main-community branch of this fork. The workflow includes validation checks and adds a comment back to the source PR with the upstream PR link.
- Automated upstream PR creation upon merge to
main-community - Branch validation to ensure changes are based on
main - Skip functionality via
no-upstreamlabel
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| echo "Checking for existing open PR to $UPSTREAM_REPO with head $REPO_OWNER:$BRANCH" | ||
|
|
||
| export GH_TOKEN="$TOKEN" | ||
| existing=$(gh pr list -R "$UPSTREAM_REPO" --state open --head "$REPO_OWNER:$BRANCH" --json number --jq '.[0].number') |
There was a problem hiding this comment.
The jq expression .[0].number will fail with 'null cannot be indexed with number' when the array is empty. Use .[0].number // empty or check array length first to handle cases where no PRs exist.
| --base "$BASE_TARGET" \ | ||
| --head "$REPO_OWNER:$BRANCH" | ||
|
|
||
| new_number=$(gh pr list -R "$UPSTREAM_REPO" --state open --head "$REPO_OWNER:$BRANCH" --json number --jq '.[0].number') || true |
There was a problem hiding this comment.
The jq expression .[0].number will fail with 'null cannot be indexed with number' when the array is empty. Use .[0].number // empty or check array length first to handle cases where no PRs exist.
| new_number=$(gh pr list -R "$UPSTREAM_REPO" --state open --head "$REPO_OWNER:$BRANCH" --json number --jq '.[0].number') || true | |
| new_number=$(gh pr list -R "$UPSTREAM_REPO" --state open --head "$REPO_OWNER:$BRANCH" --json number --jq '.[0].number // empty') || true |
| run: | | ||
| labels='${{ toJson(github.event.pull_request.labels) }}' | ||
| echo "Labels: $labels" | ||
| if echo "$labels" | grep -q '"name":"'"$SKIP_LABEL"'"'; then |
There was a problem hiding this comment.
[nitpick] The nested quoting pattern is complex and error-prone. Consider using jq to parse the labels JSON more reliably: if echo '$labels' | jq -e '.[] | select(.name == env.SKIP_LABEL)' >/dev/null 2>&1; then
| if echo "$labels" | grep -q '"name":"'"$SKIP_LABEL"'"'; then | |
| if echo "$labels" | jq -e '.[] | select(.name == env.SKIP_LABEL)' >/dev/null 2>&1; then |
| echo "An upstream PR already exists (#$existing). Exiting."; exit 0; fi | ||
|
|
||
| body_content=${PR_BODY:-"(No description provided in the source PR)"} | ||
| body_content+="\n\n(Automated upstream mirror of source PR ${REPO_FULL}#${PR_NUMBER} by @${AUTHOR})" |
There was a problem hiding this comment.
Shell string concatenation with += may not work as expected with newlines. Use body_content=\"${body_content}\n\n(Automated upstream mirror of source PR ${REPO_FULL}#${PR_NUMBER} by @${AUTHOR})\" instead.
| body_content+="\n\n(Automated upstream mirror of source PR ${REPO_FULL}#${PR_NUMBER} by @${AUTHOR})" | |
| body_content="${body_content}\n\n(Automated upstream mirror of source PR ${REPO_FULL}#${PR_NUMBER} by @${AUTHOR})" |
|
The new AI agent is quite useful 👌🏼 |
| name: Mirror merged PR upstream | ||
|
|
||
| on: | ||
| pull_request: |
There was a problem hiding this comment.
Although I do worry about the possibility of just spamming the main repo. I wonder if we shouldn't have a separate branch called upstream or something like that, because let's say if we added a new component through one PR but then realized there is something that needs to be fixed and created and merged a new PR for that, it would create 2 PRs where only one PR would possibly be necessary.
There was a problem hiding this comment.
Right, but with another branch we would have one PR with multiple components with one upstream branch
There was a problem hiding this comment.
I think that as Material Web community grows, it will make review difficult if we continuously update a single large PR
There was a problem hiding this comment.
I didn't mean for there to be one large PR. I think the main issue is that the PRs are just going to pile up because I don't have any illusions that they would potentially accept new stuff, etc, fixes maybe.
There was a problem hiding this comment.
That's true. Maybe we can do one branch per component (i.e. feat/components/<component) and then create a PR only for that (and we'll update that branch in the time). The workflow supports the no-upstream label to skip PRs
There was a problem hiding this comment.
Maybe we can do one branch per component (i.e. feat/components/<component) and then create a PR only for that (and we'll update that branch in the time).
Yep I do agree with that I think it is gonna be probably for the best
Closes #7