stable not updating after pushing new tag

[fasaxc]

Details

I moved the 1.3.0 tag to point to the latest version of 1.3.0 but stable still rebuilds using the old 1.3.0 commit. Rebuilding 1.3.0 does the right thing.

If this issue is for a specific project or build, include the following:

• Project: project-calico
• Build #: #3772260

[fasaxc]

Please can you give me a way to fix if stable ever builds the wrong thing? Right now, as soon as the user makes an incorrect tag, it's broken forever. Perhaps there could be a box in the admin UI to force stable to a particular commit?

The purity of the semver approach is nice in theory, but in practice, we all make mistakes!

[fasaxc]

I tried pushing a completely new 1.3.1 tag but stable still hasn't been updated, it still seems to be stuck on the old 1.3.0 tag. Please can you investigate?

stable seems to be building commit e28b1cb9b1700ede2a69cc6bb81b690a008676a6
Even though 1.3.0 points at 93c8be150eb8b7335da77a655bf6db8affd803ee
and 1.3.1 points at (the even more recent) bf5a7ff586092fe21a4b4faaad3d6410e2db456e

[agjohnson]

Stable isn't updated because we don't have a 1.3.1 version. I can see if this is something on the server.

[jambonrose]

I'm seeing a similar issue.

I've set the latest docs to build the development branch. When I add a new tag to development, the stable doc section does not update to the new tag, and instead remains pointed to the previous tag.

In this case, I've just pushed a release for v0.5.0 of django-improved-user. RTD shows me the new tag, and allows me to build docs for that tag without a problem. However, the stable docs sections continues to point at v0.4.0 (which is rather unhelpful, as there are no docs to be built then!).

I've tried manually building both latest and stable, but to no avail, and building v0.5.0 worked fine, but had no effect on stable.

[jambonrose]

I'm poking around the codebase, but it's brand new to me, so I'm a little lost. Happy to help here if you point me in the right direction.

Below is a screenshot of the issue I'm seeing. Note how the commit for stable (bottom) and v0.4.0 are the same, but that RTD is seeing v0.5.0.

[jambonrose]

Welp. This is embarrassing. Found the answer in the docs: 'We only consider non pre-releases for the stable version of your documentation.' Whoops. I consider the issue solved.

[humitos]

A lot of work on how stable versions are handled were done in the last year. So I'd like to know, @fasaxc, if you still have this issue?

If you don't, please close the issue.

Thanks for your report!

[micheles]

I have a similar issue. I have released a new version of my decorator module (version 4.2.0) but stable is pointing to version 4.1.1, see http://decorator.readthedocs.io/en/stable/tests.documentation.html.
If I go to the page https://readthedocs.org/projects/decorator/versions/ I see that stable is indeed pointing to origin/4.1.1, but I cannot figure out how to change that.

[stsewd]

@micheles did you try manually building the latest version? (that way the version list is refreshed)

[micheles]

Yes, I tried but it does not work. At the end I turned "stable" into inactive status, since "latest" does what I expect (i.e. points to the latest version 4.2.1 which is stable anyway) and it is good enough for me.

[stsewd]

Related to #3729, and #3714. The users solve the problem by deleting the project and creating it again (same name can be used).

[irmen]

Just piping in to say I've got the same problem (http://pyro4.readthedocs.io)

4.71 is the latest release version but stable remains stuck on the commit from the previous version.
I've tried wiping the stable build, rebuilding it, rebuilding the latest docs, setting it on inactive and activating again, but all to no avail. I've not tried deleting and recreating my project (don't really want to take it down)

[stsewd]

@pineapplemachine can you provide the build url, and project?

[pineapplemachine]

@stsewd I fixed the problem a few minutes after posting! It was my own mistake, I had not rebuilt stable. (I wrongly assumed it would have rebuilt automatically)

Sent from my Samsung SAMSUNG-SM-G891A using FastHub

[stsewd]

Everyone having this problem, it is a bug (more information on #3887). The current solution is recreating the project (the same name can be used)

[Peque]

Just for reference: I did not need to recreate the project. Simply re-building latest and stable made readthedocs.org pull the latest tag correctly.

[xylar]

I have been trying to get stable to build for my project, https://github.com/MPAS-Dev/MPAS-Analysis. The project had tags v0.43 and v0.41 that should have been v0.4.3 and v0.4.1. I have renamed the tags (by creating new tags and deleting the old ones). However, ReadTheDocs still sees the old v0.43 and v0.41 tags even many hours later. I tried deleting my ReadTheDocs project completely and recreating it but the tags remain. The latest stable version of the code is v0.7.5 but ReadTheDocs thinks it is v0.43.

It is likely that forks of my repo have these old tags still. Could that somehow be the problem?

I am curious why there is not simply an option to force ReadTheDocs delete a version that the administrator knows to be invalid.

[stsewd]

@xylar please provide your Read the Docs project url

[stsewd]

I think I found your project https://readthedocs.org/projects/mpas-analysis/

Anyway, I just import your project on my local instance and seems to be ok

If you are still having the problem you can try wiping the environment (this can be done in the Versions section, edit button)

[xylar]

@stsewd, thanks for looking into this!

Yes, that is the correct URL for our project on ReadTheDocs.

If you are still having the problem you can try wiping the environment (this can be done in the Versions section, edit button)

I tried wiping each unwanted tags with no effect.

I tried deleting the project and re-importing it, also with no effect. Could something be cached on the ReadTheDocs side when I delete a project and bring it back?

[stsewd]

Hi, all people here, the fix for this bug was already deployed, can you test if that really solves your problem? (you may need to wipe and rebuild another version).

You may need to do some additional steps if that doesn't work #3913 (comment)