-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Building latest fails at checkout #10601
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We're seeing a similar error when building |
Did you change this from GitHub or the RTD dashboard? |
We have disabled our new clone/checkout pattern while we fix this bug. |
|
So, there are a couple of problems here: - Versions have been created with the type set as unknown, and where never updated to the correct type. I was able to track down this to projects created before 2018, so probably an old bug allowed this to happen. - Stable machine versions are basically an alias for the latest stable version of the project, and they can be a branch or a tag, this means that if this version is a branch, so will be the "stable" version, same for tags. Currently, we aren't updating the version type, if the stable version was created as a branch, it will remain as a branch, even if the latest stable version is a tag, and vice versa. - Latest machine versions are basically an alias for the default branch of the project, they are always branches. Since we allow to have non-machine latest versions, they can be a branch or a tag. If this version was changed back to be a non-machine version, currently it will remain as branch or tag, this was incorrect. Our new clone/checkout pattern relies on the type of the version always being correct, so it was failing for some projects. - Fixes #10600 - Fixes #10601 After deploy, we need to clean up the invalid versions (versions with "unknown" type). We can do that by: - Updating all latest machine versions to be branches. ```python Version.objects.filter(type="unknown", machine=True).update(type="branch") ``` - Re-evaluate the stable version of all projects that have a machine stable version, so they can have the correct type. ``` for project in Project.objects.filter(versions__machine=True).distinct(): project.update_stable_version() ``` - Check all remaining active versions with "unknown" type, and update them to be branches or tags (324). We can use a simple regex to see the version identifier looks like a commit. ```python vesions = Version.objects.filter(type="unknown", active=True) commit_regex = re.compile(r"^([a-f0-9]{40})|([a-f0-9]{7})$") for version in versions: if commit_regex.match(version.identifier): version.type = "tag" else: version.type = "branch" version.save() ```
Also seeing this in 2 recent PR builds (retrying didn't help) |
Looks like something just changed as checkout failures are showing up for this PR ( zarr-developers/numcodecs#442 ):
However these didn't occur in a previous PR ( zarr-developers/numcodecs#455 ) ~40mins ago |
@jakirkham hi, your problem isn't related to this issue, but looks like it was probably a temporal problem from GitHub? I wasn't able to replicate that problem outside RTD, and also triggered a new build https://readthedocs.org/projects/zarr/builds/21561782/, and it went okay. But let us know if you see this problem again. |
Thanks Santos! 🙏 Ah ok. That may be. Didn't immediately think it was GitHub related as the GitHub Actions jobs seemed to run ok Retried the Numcodecs PR above as well and that seems to be working now too Sorry for the noise |
* Versions: keep type of version in sync with the project So, there are a couple of problems here: - Versions have been created with the type set as unknown, and where never updated to the correct type. I was able to track down this to projects created before 2018, so probably an old bug allowed this to happen. - Stable machine versions are basically an alias for the latest stable version of the project, and they can be a branch or a tag, this means that if this version is a branch, so will be the "stable" version, same for tags. Currently, we aren't updating the version type, if the stable version was created as a branch, it will remain as a branch, even if the latest stable version is a tag, and vice versa. - Latest machine versions are basically an alias for the default branch of the project, they are always branches. Since we allow to have non-machine latest versions, they can be a branch or a tag. If this version was changed back to be a non-machine version, currently it will remain as branch or tag, this was incorrect. Our new clone/checkout pattern relies on the type of the version always being correct, so it was failing for some projects. - Fixes #10600 - Fixes #10601 After deploy, we need to clean up the invalid versions (versions with "unknown" type). We can do that by: - Updating all latest machine versions to be branches. ```python Version.objects.filter(type="unknown", machine=True).update(type="branch") ``` - Re-evaluate the stable version of all projects that have a machine stable version, so they can have the correct type. ``` for project in Project.objects.filter(versions__machine=True).distinct(): project.update_stable_version() ``` - Check all remaining active versions with "unknown" type, and update them to be branches or tags (324). We can use a simple regex to see the version identifier looks like a commit. ```python vesions = Version.objects.filter(type="unknown", active=True) commit_regex = re.compile(r"^([a-f0-9]{40})|([a-f0-9]{7})$") for version in versions: if commit_regex.match(version.identifier): version.type = "tag" else: version.type = "branch" version.save() ```
Works for us: https://readthedocs.org/projects/scrapy/builds/21626059/ |
FWIW this worked for us with Zarr & Numcodecs |
Details
Expected Result
After changing the default branch to just created 2.10 I saw that building
latest
failed. To make sure it's not a problem at our side I changed the default branch back to 2.9 andlatest
fails to build too.Actual Result
The build runs the following commands:
After I do the same manually I see that the local repo indeed doesn't contain a
2.9
branch, or any other branch exceptmaster
andremotes/origin/master
.The text was updated successfully, but these errors were encountered: