Integration Tests - anything using GetBadCredentials will fail if using auth token

[Red-Folder]

A number of integration tests use the Helper.GetBadCredentialsClient()

This function uses the existing credentials to create an invalid credentials (using the current login).

However if you are testing with an auth token, then the current credentials will not have the login (just the auth token).

To fix - just needs a bit of tidy up in the helper.

[Red-Folder]

Also noted that this breaks other Integration tests:

CreateHook in RespositoriesHooksFeature

Basically anything that will be using Helper.Credentials.Login

[Red-Folder]

Arggggg ... keep hitting:

Octokit.ForbiddenException : You have triggered an abuse detection mechanism and have been temporarily blocked from content creation. Please retry your request again later.

Related to: https://developer.github.com/v3/#abuse-rate-limits

May need to introduce a sleep into the integration tests somewhere to void hitting

[Red-Folder]

Ok ... mental note to self - if using Personal Access Token for integration testing - make sure if has the relevant Scopes (was missing delete_repo)

[Red-Folder]

Following integration tests seems to fail if using OAuth, but not username/ password:

• PullRequestsClientTests.CanSortPullRequests

Following integration tests fail regardless of credentials:

• RepositoryDeployKeysClientTests.CanRetrieveAllDeployKeys - Validation Failed
• ObservableRespositoryDeployKeysClientTests.CanRetrieveAllDeployKeys - Observable version of the above
• Octokit.Tests.Integration.RedirectTests.CanCreateIssueOnRedirectedRepository - A task was cancelled (think this is timing out)

[Red-Folder]

Ok, the 2 x DeployKeys fails where due to test fragility - I've logged those as a separate issues #873

[Red-Folder]

Separated out the CanCreateIssueOnRedirectedRepository as a separate issue #874

I think this is actually a bug in the core redirect code, rather than the Integration tests

[shiftkey]

However if you are testing with an auth token, then the current credentials will not have the login (just the auth token).

That's a great point. Nice spot!

Ok ... mental note to self - if using Personal Access Token for integration testing - make sure if has the relevant Scopes (was missing delete_repo)

There's a way to check what scopes you have defined, but I've not spent much time with this. We could investigate scripting this out to verify it.

[immeraufdemhund]

Just ran into this sort of in production. Was trying to access enterprise repository to auto log a issue. Kept trying to create an issue using my auth token and I was getting error 404. After much trial and error found out I had to use the new Credentials(string, string) overload when creating a client.

[ryangribble]

or grant the correct scope to your auth token?

[immeraufdemhund]

We created a test repo for testing and created a auth token with every possible option checked. Testing

.Credentials = New Credentials("MyTokenHere") //fails
.Credentials = New Credentials("MyUserName", "MyTokenHere") //works
.Credentials = New Credentials("SomeMadeUpName", "MyTokenHere") //works

yes i really used SomeMadeUpName :) I laughed that it worked.

[ryangribble]

I can reproduce what you are seeing where the GitHub API does honour the request when the token is provided as the password, no matter what username is specified. I guess this is just how it behaves so there isn't anything we should really worry about in that case...

However I CAN'T reproduce your first case (using the token as it is normally intended to be used, via the OAUTH type constructor and authenticator in octokit).

This is a personal access token right? And in addition to the token scopes, you have ensured the given user (who owns the token) has the correct permissions on the repository in question?

I can create a client with a .Credentials = New Credentials("MyTokenHere") and then succesfully create issues etc.

Are you able to post a more complete code sample for the first issue?

[github-actions]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!