feat: update octokit

[jugaltheshah]

Deprecated - Github username & password auth:
As Github has deprecated REST API auth via username & password, this no longer works as an auth mechanism. After this PR, shepherd will still support auth via .netrc, but the .netrc.password field should supply a token instead of a Github password.

Updates:

• "@octokit/rest": "^15.18.1" -> "@octokit/rest": "^18.0.12",,
  • octokit methods, e.g. octokit.pullRequests.update -> octokit.pulls.update

[aorinevo]

@nwalters512, I recommend bumping the major version here and providing support for the last 2 major versions. Thoughts?

[aorinevo]

@jugaltheshah, as this is a breaking change, let's bump the major version.

[jugaltheshah]

@nwalters512, I recommend bumping the major version here and providing support for the last 2 major versions. Thoughts?

That was the intent with the "breaking change" in the PR description though come to think of it, I'm not sure if that's a custom option that this repo doesn't have enabled. Regardless, I'll update the PR title, which should do the same.

Please be sure to squash & merge this PR so semantic bot will cut a new major release

[aorinevo]

@nwalters512, I recommend bumping the major version here and providing support for the last 2 major versions. Thoughts?

That was the intent with the "breaking change" in the PR description though come to think of it, I'm not sure if that's a custom option that this repo doesn't have enabled. Regardless, I'll update the PR title, which should do the same.

Please be sure to squash & merge this PR so semantic bot will cut a new major release

Need to confirm that this is the expected behavior.

[aorinevo]

@jugaltheshah, mind squashing the commits down prior to merging this down. In addition, can you follow the message commit format is specified in [1].

References

1. https://www.conventionalcommits.org/en/v1.0.0/

[nwalters512]

I recommend bumping the major version here and providing support for the last 2 major versions. Thoughts?

Is the breaking change the difference in how .netrc works? I'm on board with calling this v2, yeah.

By "providing support for the last 2 major versions", do you mean backporting future changes to v1? I don't think that'll be necessary.

[jugaltheshah]

I recommend bumping the major version here and providing support for the last 2 major versions. Thoughts?

Is the breaking change the difference in how .netrc works? I'm on board with calling this v2, yeah.

By "providing support for the last 2 major versions", do you mean backporting future changes to v1? I don't think that'll be necessary.

That's an interesting question actually. I'm actually now questioning if we actually need to mark this as breaking.

Yes, the reason this PR is currently breaking is the difference in how .netrc works. However, the docs say you can use a token in place of a password for clients that only support basic auth. So I'm wondering, can we can keep the existing .netrc un/pw flow, but assume the password supplied is actually a token?

So then if we keep .netrc and use the supplied username & password (token), would this still be breaking (keeping in mind that using password as password hass been broken)?

cc @aorinevo

[aorinevo]

Netrc should still work, right? It would potentially start to degrade during the brownout period and then be fully non-functional when username/password is deprecated.

I'm still in favor of doing a major version bump.

[aorinevo]

I recommend bumping the major version here and providing support for the last 2 major versions. Thoughts?

Is the breaking change the difference in how .netrc works? I'm on board with calling this v2, yeah.

By "providing support for the last 2 major versions", do you mean backporting future changes to v1? I don't think that'll be necessary.

Security and bug fixes only for the last major version - no backporting of features/enhancements.

[jugaltheshah]

Netrc should still work, right? It would potentially start to degrade during the brownout period and then be fully non-functional when username/password is deprecated.

I'm still in favor of doing a major version bump.

Using username & password against the Github REST API was already deprecated as of November 13th, 2020 per this doc.

I think what's causing some confusion here is that Github deprecated using username:password auth, but not basic auth via username:token with token used like a password. So if your Github username & password were user1:password123, using those against the Github API won't work. However, if you generate a personal access token on Gihub.com and use user1:token123 against the Github API, I believe this will still work (this is what I still need to confirm). They did this for compatibility with clients that only support basic auth. Of course we don't actually need a username since tokens are associated with users already, so really we'd just need to assume a password provided is a token.

So we have a couple options:

1. Keep using .netrc but re-purpose the login field to be used as a token --> breaking, but I believe this is what octokit/netrc does. This is what this PR currently does also.
2. Keep using .netrc, keep reading from password, but assume password provided = Github token, not Github password --> not necessarily breaking*

• Not necessarily breaking from our perspective because as previously noted, this would have already been broken as of mid-Nov of last year. If users currently have their Github password in .netrc, it shouldn't work, but if they update it to a personal access token and we go with option 2, it should work.

We could err on the side of caution here and release a major version regardless, but just wanted to present the options as I saw them.

[aorinevo]

Ah, I see now. That makes sense.

I'm in favor of option 2 and keeping this a minor bump.

[aorinevo]

Many thanks for this contribution @jugaltheshah! 🚢

[aorinevo]

🎉 This PR is included in version 1.13.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀