WIP: Create repo project with GraphQL API

[gclhub]

Classic projects can no longer be created through the REST API, and the only reference to the project in the training repository is a screenshot showing the GitHub.com UI in the slide deck. The project itself is not used during the class, so it should be safe to remove it since the teach-class script returns spurious HTTP errors as noted in #379.

Fixes #379

[amyschoen]

Do we want to remove it or should we just make this work? From the documentation, it looks like we should just need an additional header:

-H "X-GitHub-Api-Version: 2022-11-28" \

[gclhub]

Do we want to remove it or should we just make this work? From the documentation, it looks like we should just need an additional header:

-H "X-GitHub-Api-Version: 2022-11-28" \

I believe I tested that manually at the command line before creating the PR, but let me double-check that today and paste the results. I also found a reference here that classic projects need to be enabled on the repository for this endpoint to work: https://docs.github.com/en/rest/projects/projects?apiVersion=2022-11-28#create-a-repository-project

I had projects enabled on the repository in question, but I still received a 410 HTTP error, so I assumed that meant that classic projects were not enabled.

I also looked at whether the GraphQL API could be used but didn't find a way to create a repository project yet, just a generic project creation endpoint: https://docs.github.com/en/graphql/reference/mutations#createproject

[amyschoen]

Interesting. If your testing still shows it doesn't work, I'd be fine with removing it for now. If we go that route, I would like to log an issue to add it back once the APIs are in place again.

I have some experience working with the GraphQL APIs including some scripts that use a combination of both v3 and GraphQL because each API has its strengths and capabilities depending on what you need to do. Since we have the shared-functions script now, it'd definitely be doable to throw it into the mix. The questions I can think of there are:

• Do we want to have a hybrid mix of v3 and GraphQL or is that going to add too much complexity for the folks working on the scripts?
• If we add GraphQL, do we want to do a refactor to just convert our scripts completely to GraphQL?

I can work with either, but I can't guess on whether the rest of the trainers would be okay with adding in GraphQL.

[gclhub]

Here's the output from manually running the project creation command after the script/teach-class script finishes and displays a few HTTP errors while attempting to create a project. I pulled the project creation command from the script and ran it manually as shown. I changed the Accept header value slightly based on the current REST API docs:

$ http --check-status --ignore-stdin --auth \
    "$TOKEN_OWNER:$TEACHER_PAT" https://api.github.com/repos/ps-developers-sandbox/script-test-2-gcl/projects "Accept:application/vnd.github+json" "X-GitHub-Api-Version: 2022-11-28" name="Test Project" body="This is my test project"
HTTP/1.1 410 Gone
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
Content-Length: 113
Content-Security-Policy: default-src 'none'
Content-Type: application/json; charset=utf-8
Date: Wed, 08 Feb 2023 18:49:29 GMT
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Server: GitHub.com
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Vary: Accept-Encoding, Accept, X-Requested-With
X-Accepted-OAuth-Scopes: public_repo, repo
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-GitHub-Media-Type: github.v3; format=json
X-GitHub-Request-Id: D879:8431:34A280:366487:63E3EEB9
X-OAuth-Scopes: project, repo
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4980
X-RateLimit-Reset: 1675884009
X-RateLimit-Resource: core
X-RateLimit-Used: 20
X-XSS-Protection: 0
github-authentication-token-expiration: 2023-04-27 17:37:29 UTC
x-github-api-version-selected: 2022-11-28

{
    "documentation_url": "https://docs.github.com/v3/projects",
    "message": "Projects are disabled for this repository"
}

In order to get project creation working, I think it would be reasonable to migrate that part of the script to GraphQL to fix the immediate issue and then migrate the rest of the API calls to GraphQL at a later date.

As a new employee, one of my near-term goals is to learn GraphQL better, so I would be interested in assisting with or reviewing the refactored code, if that's acceptable.

[gclhub]

Adding a few further notes here for reference. After some digging, it looks like passing a repository ID to the mutation that creates a project may be the way to replicate the previous REST API functionality:

https://docs.github.com/en/graphql/reference/input-objects#createprojectv2input

I haven't tested it yet, but maybe switching the ownerID in this mutation to repositoryID would be the way to do it: https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/using-the-api-to-manage-projects#creating-projects

[amyschoen]

Since you mentioned being new, here's a query that might come in handy.

query = """
        query GetRepo($org_name:String!, $repo_name:String!) {
            repository(name: $repo_name, owner: $org_name ) {
                id
                isArchived
            }
        }
    """

One of the gotchas I hit on combining the two APIs is that the repo ids are different between the two. Took me a bit of time to figure out why my updates weren't behaving as expected. If I'm recalling correctly, the id under repo in GraphQL is the same as the node_id field that comes back from v3.