add active lock reason to issue

[notauserx]

Added LockReason enum, added activelockreason property to Issue class.

Fixes issue #2248

[notauserx]

I need some feedback on this.
Also, do I add the ActiveLockReason on the PullRequest class as well?

[JonruAlveus]

Hey so it would be good to see an integration test covering this, in IssuesClientTests in Octokit.Tests.Integration.

If you want to add it to PullRequest as well, that would be great! But if you don't, add it as a new issue so we can track it 👍

[notauserx]

Hey @JonruAlveus, thanks for the input. However, I can't seem to run all of integration tests.

Am I missing something?

[JonruAlveus]

If you head over to here there's instructions on how to set up test accounts for the integration tests to run in. You don't need all of the settings, but try to use a separate github account to your own as you could easily get yourself locked out of github for exceeding api rate limits 😄

I believe you need the first two as a minimum: OCTOKIT_GITHUBUSERNAME and OCTOKIT_GITHUBPASSWORD, which are set as environment variables on your machine.

[notauserx]

Thanks @JonruAlveus, I'll give it a go. I have updated the PR with a sample test. Will update when I can set up the test.
I have changed the signature of the lock method on IIssueClient for allowing to set the lock reason. I've made the LockReason parameter optional so I don't have to change all the references.
Feel free to review my changes.

[notauserx]

Added CanAccessActiveLockReason on IssuesClientTest and the test is passing.
However, getting "warning: CRLF will be replaced by LF in Octokit/Clients/IssuesClient.cs."
What is the default line ending for the project?

[nickfloyd]

Hey @notauserx EOL in this repo should be lf - you can run git ls-files --eol to validate this in this and other projects in the future if you'd like.

[notauserx]

@nickfloyd line endings seems to be correct for the files I modified.

[JonruAlveus]

Judging by the gitattributes documentation (effects section) (and I’m not an expert on this at all), when you got add or got commit, the line endings are set according to the file. So I guess you could change the line endings and they will just be sorted out when you add/commit.

[nickfloyd]

Judging by the gitattributes documentation (effects section) (and I’m not an expert on this at all), when you got add or got commit, the line endings are set according to the file. So I guess you could change the line endings and they will just be sorted out when you add/commit.

For sure... for .cs files as defined in our .gitattributes file it's LF.

I used to config my local global, just in case the repo I am working in does not have .gitatributes to be - core.autocrlf true on windows and core.autocrlf input on mac that way my changes end up being the more common LF even if the repo owner doesn't have one set. I haven't encountered those issues in years, so I generally leave it as is.

All that to say, for *.cs files and all other files, we should follow what is defined in .gitattribtues for consistency's sake. If that's not working as it should, we need to look at that and understand why.

[nickfloyd]

Just a quick change around the enum value name - looks like a typo. This is looking good, let me know when you take it out of WIP / Draft, and we can get this merged in.

[notauserx]

@nickfloyd thanks for the review and the catch. I've committed your suggestion and removed wip from the name.
Please merge if the PR looks good.

[nickfloyd]

Thanks for the changes ❤️

[nickfloyd]

release_notes: Adds active lock reason to issue