Github Tags Are NOT in Chronological Order

[therynamo]

Issue

When comparing commits, tags that are alphabetical are showing up before numerical tags. This causes the comparisons to fail and therefore report nothing.

Cause

https://stackoverflow.com/questions/19452244/github-api-v3-order-tags-by-creation-date

This is an existing and intended feature by github when using the v3 API.

The interesting thing here is that it is possible to sort by date using the v4 GraphQL API.

Fix

There will need to be some discovery work here on what the right way to proceed is.

[therynamo]

After investigating further, we'll most likely take a tapered approach to this issue.

In order to support both OSS github and enterprise users, we'll need to wait until this schema change reaches enterprise users.

For now we'll take the following approach:

• Major version release will allow all OSS github users to use API v4
• Minor patch will fix this issue by using a v3/v4 bridge. Use v4 for fetching tags, and v3 for everything else
• Once the GHE schema changes are live they will be able to use the latest major version and take advantage of the v4 api

[therynamo]

Here is the github community issue that helped find the solution to the v4 api.

The query should look something like this:

query GetAssociatedPRsViaTags {
  repository(owner: "owner", name: "repo") {
    name
    refs(
      refPrefix: "refs/tags/"
      first: 100
      orderBy: { field: TAG_COMMIT_DATE, direction: DESC }
    ) {
      edges {
        node {
          name
          target {
            ... on Commit {
              history(first: 100) {
                edges {
                  node {
                    associatedPullRequests(
                      first: 100
                      orderBy: { field: CREATED_AT, direction: ASC }
                    ) {
                      totalCount
                      edges {
                        node {
                          title
                          createdAt
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

This query will need to be optimized for the associatedPullRequests. If a repository doesn't squash and merge then they could have potentially hundreds-thousands of commits in between releases. So we'll need to find a way to pass in a value that will utilize the since field to look at commits in the time frame between releases.

I'm open to better solutions, but this is a good starting point.

[therynamo]

Adding to the list of reasons to upgrade.

The v3 search api supports only 30 requests per minute, looking into whether or not GraphQL can fix this or not could be very helpful. We've been hitting the rate limits on search consistently for multiple projects now.