Open btlogy opened 1 month ago
@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.
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: 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.
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):
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).
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.
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?
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.
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}"
Thus, in #467, I'm trying to avoid the ssh key required to checkout (just not working well with Windows).
Possibly related to #454
@crwood has been trying to debug this in #461
Thus, 5 jobs are still failing: