Some Circle-CI checks are failing and blocking a new release

[btlogy]

Possibly related to #454

@crwood has been trying to debug this in #461

Thus, 5 jobs are still failing:

• windows-tests-3.9
• windows-tests-3.10
• macos-test-3.9-13.4.1
• macos-test-3.10-13.4.1
• linux-test-39-dev

[btlogy]

@laurih01: both @hacklschorsch and @btlogy would like to have Write/Commit access to this repository, so we could "Rerun jobs with SSH" in Circle-CI.

[btlogy]

I've managed to reproduce the same test error locally using nix build --verbose .#tests-python39-tahoe_1_18_0-ci-cov:

_zkapauthorizer.tests.test_client_resource.RecoverTests.test_conflict id=0x7ffff5091a90> took longer than 60.0 seconds

It seems to me that the ci profile which requires max_examples=200 is indeed hitting this timeout of 60s, no matter with which version of tahoe we pick.
This build triggered by @hacklschorsch are confirming that the failure of those linux-tests are transient.

[laurih01]

@laurih01: both @hacklschorsch and @btlogy would like to have Write/Commit access to this repository, so we could "Rerun jobs with SSH" in Circle-CI.

Done, you both have maintain access now.

[btlogy]

Now I've maintainer access, I've been playing around with CircleCI and I'm not happy with my understanding so far:

No matter if it is a public repo (unless there is a way to pull via https) CircleCI needs a private ssh key to checkout the code from GitHub.

There is apparently 3 ways to provide an ssh key to CircleCI (at the project level):

1. CircleCI can conveniently create a private key and use GitHub OAuth to authorize the public part as a deploy key for the related project only. But I suspect this to work only if the acting user has admin permissions on the repo (nothing happens for me).
2. CircleCI can conveniently create a private key and use GitHub OAuth to authorize the public part as a user key, which allow CircleCI to then act as the user who has enabled that feature for the project !
3. CircleCI propose to manually create an ssh key pair and upload the private part in the CircleCI project while the public part will also have to be manually authorized in other places (not only GitHub then).

I just went down the road with option 2 and it works. But I now have authorize CircleCI to act as @btlogy with all my user permissions on GitHub!? So I've removed that key right after the checkout steps were successful.

I suspect only a GH repo Admin such as @laurih01 could try option 1.
I'd like to try option 3, but it also requires Admin permission to make it right, likely using a machine user...

I suspect this option 2 (or 3) could have been previously enabled by a former team member who has since removed the related key. This would explain the current broken state of the CircleCI (also for Tahoe-LAFS I think).

[hacklschorsch]

There is apparently 3 ways to provide an ssh key to CircleCI (at the project level):

This sounds terrible and I am confused. I do not see any private ssh key from CircleCI in my GitHub account or the ZKAPAuthorizer repo. I thought what CircleCI did was just get my public ssh keys (even without a login available at https://github.com/hacklschorsch.keys) and put them in the authorized_keys file on an SSH-enabled runner.

[hacklschorsch]

For pushing a release, for example, CircleCI needs more access than that of course - IDK how they do that. Is that what you referred to above?

[btlogy]

I thought what CircleCI did was just get my public ssh keys (even without a login available at https://github.com/hacklschorsch.keys) and put them in the authorized_keys file on an SSH-enabled runner.

The ssh keys I was referring above are the (private) ones CircleCI needs to checkout the code from GitHub.
Not to be confused with the (public) one CircleCi needs to authorize maintainers to access their runner for debugging.

[btlogy]

For pushing a release, for example, CircleCI needs more access than that of course - IDK how they do that. Is that what you referred to above?

Maybe, or maybe not.
After looking a bit closer to the current release workflow, I do not think it is pushing anything on GitHub yet.
I believe it only gets triggered by new tag pushed on GitHub, and then build the wheel and upload it on PyPi.
And this requires a secret, just not an ssh key: TWINE_PASSWORD="${PYPI_API_TOKEN}"

[btlogy]

Thus, in #467, I'm trying to avoid the ssh key required to checkout (just not working well with Windows).