copyIssueProjectsToPR does not work for Projects

[bagermen]

I guess copyIssueProjectsToPR works for Classic Projects but not for new Projects.

The query shows me my project:

projectItems(first: 1) {
  nodes {
    project {
      id
    }
  }
}

This one return empty results

projectCards {
  nodes {
    project {
      id
    }
  }
}

There should be at least a note for that in the documentation

[create-issue-branch[bot]]

Branch issue-922-copyIssueProjectsToPR_does_not_work_for_Projects created!

[robvanderleek]

Hi @bagermen

You are right, it broke for the "new" projects, thanks for the detailed issue!

So far, I'm able to query "classic" and "new" projects IDs:

query ($owner: String!, $repo: String!, $number: Int!) {
    repository(owner: $owner, name: $repo) {
      issue(number: $number) {
        projectCards {
          nodes {
            project {
              id
            }
          }
        },
        projectItems(first: 10) {
          nodes {
            project {
              id
            }
          }
        }
      }
    }
  }

Unfortunately, I'm unable to use the IDs from the projectItems part in the mutation for the pull-request. The following mutation gives the error message "Could not resolve to Project node with the global id of 'PVT_kwDOBL_hb84ApI2u'":

mutation ($pullRequestId: ID!, $projectIds: [ID!]) {
  updatePullRequest(
    input: {pullRequestId: $pullRequestId, projectIds: $projectIds}
  ) {
    pullRequest {
      id
    }
  }
}

I'm using the GitHub GraphQL explorer for testing.

One difference I noticed in the query is that for "new" projects, the node type is "Projectv2", where the error message mentions a "Project" node. But I'm not sure if that's causing the error.

It would be helpful if you could verify the above behavior on your own projects/PRs.

Kind regards, Rob

[bagermen]

@robvanderleek I have found out this documentation "automating-projects-using-actions". The link includes code examples of ability to link PR to project. I guess this article could be used as a starting point for the problem solution.

To be true, I think that link of PR/issue to project it's functionality which deserves independent action. If you look at default workflows for github projects, they split workflows and the reason: issue/pr may have different status or different behavior. so, ideally, it would have been having workflows that repeat functionality of default workflows but with additional functionality.

[robvanderleek]

Hi @bagermen

Thanks for that link! It contains the GraphQL call I needed for ProjectV2 support: addProjectV2ItemById

I've added support for all project types (classic & new) to the staging branch, for an example of how it works see this issue.

Unfortunately, the default GITHUB_TOKEN for GH Action workflows does not have sufficient permissions to access all information (new projects are now part of the user/org, no longer the repository). This means you'll have to create a custom token for these workflows. See this workflow for how I use the staging action with a custom token.

Let me know if this solution fits your use-case. I do agree it becomes quite complex to handle everything in a single action, then again, maintaining multiple workflows is also a hassle.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.