This moves our existing test plan under a "Required testing" section.
We're also adding the scenarios used for testing live results under an "Optional testing" section.
I believe this doesn't change the user-visible behaviour at all. The user
won't be prompted to log in any more or less often than they would have
done before.
One benefit of this is that we can remove the registerListeners method
because we no longer need to know if the cached octokit is still valid.
Instead we just call vscode.authentication.getSession every time and it
will return the current session, which might be different from the last
time we called it. This might prompt the user to log in, but that would
have happened anyway because when the session changed we would have
overwritten our cached octokit instance.
Another benefit is that we no longer need the extension context and this
removed a surprisingly large amount of code where we are passing this
parameter around because we need it for the credentials.
The only downside I can see is that we call getSession more often and
create more javascript objects in general. I believe the performance
impact of this will be negligible and not worth worrying about.
I argue that calling createOctokit(false) adds no benefit. If an
authenticated session already exists then this silently create an
octokit, which makes getOctokit() a no-op just returning the field.
However if there is already an authenticated session then getOctokit()
would already be able to create an octokit without prompting the user.
On the other hand if there isn't an authenticated session then we
won't be able to pre-populate an octokit, so getOctokit() will have
to prompt the user anyway.
Not calling createOctokit(false) in registerListeners also doesn't
change behaviour. If the user is authenticated in the new session then
we would be able to create an octokit instance wihtout prompting in
getOctokit anyway. If the user is not authenticated in the new session
then we won't be able to create an instance without prompting either way.
The only benefit I can think of is that it moves a tiny amount of
computation earlier in the pipeline, but the amount of computation is
tiny and it isn't any more async than it would be if it happened in
getOctokit(). I don't think this is worth making the code more complex.
This was only used from initializeWithToken and only added a completely
separate case to the start of the method, effectively turning it into
two separate implementations. Therefore we can make things simpler by
inlining this case in the one place it is used.
It is true by default and no place in the codebase sets it to false. We can
simplify the code by removing this case we aren't using. If we want this
behaviour in the future we can always implement it again, but I think it's
likely to be unnecessary and if you don't want authenticated requests then
you likely won't be initializing a Credentials object.
This cannot happen already, even before the other changes in this PR.
The Credentials.initialize method can never return undefined, so these
checks would never return true. The real place that checks that we are
authenticated is in the vscode.authentication.getSession method, and
it will reject the promise if the user declines to authenticate or
anything else means we can't get an authenticated session.
I feel justified in removing the tests for these cases because the
code was never actually called in production, and we are covered by the
vscode authentication library rejecting the promise. Any exception
thrown from Credentials.initialize would behave the same as the one I'm
deleting.
Charis Kyriakou
Elena Tanasoiu
Shati Patel
Nora
Robert
Koen Vlaswinkel
dependabot[bot]
Charis Kyriakou