Cannot read property 'target' of null

[ronkorving]

Cannot read property 'target' of null

[sorenlouv]

@ronkorving I've started a PR in #160. You can try it out by installing the beta version

yarn global add backport@beta or npm install -g backport@beta

LMK how it goes 🤞

[sorenlouv]

Hi @ronkorving,

Thanks for making me aware of this.
I would love to be able to reproduce this scenario. Thinking through it, I don't understand how it can occur. Before the error occurs there are a couple of sanity checks:

• does the repo exist?
• is the access token valid?
• does the access token have the required scopes to access the repo?

In this case all the three checks passed. Which makes me wonder why res.repository.ref is null 🤔

A silly solution would be to check whether res.repository.ref is null and then return early. But that won't help you (the program won't crash but you won't be able to backport either).

Github has a GraphQL Explorer which lets you execute graphql requests: https://developer.github.com/v4/explorer/

Can you try running the following query(it's identical to the query executed by backport):

query getCommitsByAuthorQuery($repoOwner: String!, $repoName: String!, $commitsCount: Int!, $authorId: ID, $historyPath: String) {
  repository(owner: $repoOwner, name: $repoName) {
    ref(qualifiedName: "master") {
      target {
        ... on Commit {
          history(first: $commitsCount, author: {id: $authorId}, path: $historyPath) {
            edges {
              node {
                oid
                message
                associatedPullRequests(first: 1) {
                  edges {
                    node {
                      repository{
                        owner {
                          login
                        }
                        name
                      }
                      number
                      timelineItems(last: 20, itemTypes: CROSS_REFERENCED_EVENT) {
                        edges {
                          node {
                            ... on CrossReferencedEvent {
                              source {
                                __typename
                                ... on PullRequest {
                                  state
                                  baseRefName
                                  commits(first: 20) {
                                    edges {
                                      node {
                                        commit {
                                          message
                                        }
                                      }
                                    }
                                  }
                                }
                              }
                            }
                          }
                        }
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

With these variables adjusted to your repo:

{
  "repoOwner": "TODO",
  "repoName": "TODO",
  "commitsCount": 1
}

[ronkorving]

I've run your query in the GitHub GraphQL Explorer as you suggested.

Assuming repoOwner is the GitHub account name (not some ID) owning the repo (in my case, the organization I work for), and the repoName being the name (not some ID) of the repo I'm interested in, the result is:

{
  "data": {
    "repository": {
      "ref": null
    }
  }
}

When I change the repoOwner to my own username instead of the organization name, I do get a valid-looking response! But we need the upstream repo owner here, right?

[ronkorving]

I just found out what it is! The query in backport assumes that my upstream branch is called master, but in our case it's not. We maintain multiple upstream versions, and we named our "master" branches after those versions, eg: v0-master and v1-master, and we no longer have a master branch.

If I change the query to look for ref(qualifiedName: "v1-master") {, backport starts working!

To clarify how we use upstream branches:

We have N master-branches, one for every major version of our software that we want to keep supporting. For example, we support major versions 0, 1 and 2, so we keep v0-master, v1-master and v2-master around. On each branch, we have tagged releases, for example the latest ones being: v0.6.1, v1.2.3 and v2.0.1.

We have configured v2-master to be the default branch on GitHub, so pull requests automatically target the very latest.

We usually send a pull request to v2-master, and we may want to backport these patches to v1-master and maybe even v0-master.

Sometimes we will send a pull request to v1-master to patch a bug in an older, maintained version, and we'll want to backport that to v0-master. That bug may not exist on v2-master, so no PR ever goes there.

My proposal for backport:

Today we can configure the branches to backport to. I propose we make the branches to backport from configurable as well. To allow the use cases I describe above, my proposal is to introduce these 3 changes:

1. Make the upstream branch from where we source commits configurable, perhaps with a pattern (in our case /v[0-9]+-master/ for example) so we can filter out noise.
2. Allow a default upstream branch to be configured (in our case v2-master for example).
3. If no default upstream branch is configured, default to the branch that on GitHub is configured as the default-branch (which in our case, would always be the latest vN-master).

Thoughts?

[sorenlouv]

That's a great find! To paraphrase what you suggested:

The upstream branch should default to the default branch on github (in you case v2-master). Additionally it should be possible to manually set the upstream branch like

backport --upstream-branch v1-master

[ronkorving]

@sqren Sounds like we may be on the same page.

To rephrase my suggestion:

• if an upstream-branch is provided via configuration or CLI argument, it uses that
• else the interactive UI shows all upstream branches, and preselects the branch that is configured on GitHub as the default branch.

I think the GitHub default branch is useful for a good user experience, but you should be able to select a different one. So if you don't provide one, you need the ability to select a branch, I think. I'm not sure if that's already what you had in mind?

[ronkorving]

@sqren Assuming you're onboard, shall we make a new issue for this?