Skip to content

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

Closed
wRAR opened this issue Aug 4, 2023 · 11 comments · Fixed by #10606
Closed

Building latest fails at checkout #10601

wRAR opened this issue Aug 4, 2023 · 11 comments · Fixed by #10606
Assignees

Comments

@wRAR
Copy link

wRAR commented Aug 4, 2023

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 and latest fails to build too.

Actual Result

The build runs the following commands:

git clone --depth 1 https://github.com/scrapy/scrapy.git .
git fetch origin --force --prune --prune-tags --depth 50
git checkout --force 2.9

After I do the same manually I see that the local repo indeed doesn't contain a 2.9 branch, or any other branch except master and remotes/origin/master.

@heyman
Copy link

heyman commented Aug 7, 2023

We're seeing a similar error when building latest for Locust:

https://readthedocs.org/projects/locust/builds/21530410/

@stsewd
Copy link
Member

stsewd commented Aug 7, 2023

After changing the default branch to just created 2.10 I saw that building latest failed.

Did you change this from GitHub or the RTD dashboard?

@stsewd
Copy link
Member

stsewd commented Aug 7, 2023

We have disabled our new clone/checkout pattern while we fix this bug.

@wRAR
Copy link
Author

wRAR commented Aug 7, 2023

Did you change this from GitHub or the RTD dashboard?

RTD, at https://readthedocs.org/dashboard/scrapy/advanced/

@github-project-automation github-project-automation bot moved this to Planned in 📍Roadmap Aug 7, 2023
stsewd added a commit that referenced this issue Aug 8, 2023
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()
  ```
@jakirkham
Copy link
Contributor

Also seeing this in 2 recent PR builds (retrying didn't help)

@jakirkham
Copy link
Contributor

jakirkham commented Aug 9, 2023

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

@stsewd
Copy link
Member

stsewd commented Aug 9, 2023

@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.

@jakirkham
Copy link
Contributor

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

@github-project-automation github-project-automation bot moved this from Needs review to Done in 📍Roadmap Aug 10, 2023
stsewd added a commit that referenced this issue Aug 10, 2023
* 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()
  ```
@humitos
Copy link
Member

humitos commented Aug 16, 2023

@wRAR @heyman Hi! We've deployed a fix for this case. Please, let us know if it's working as you expected 👍🏼

@wRAR
Copy link
Author

wRAR commented Aug 16, 2023

Works for us: https://readthedocs.org/projects/scrapy/builds/21626059/

@jakirkham
Copy link
Contributor

FWIW this worked for us with Zarr & Numcodecs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants