lastversion: lastversion returns None randomly

I’m using lastversion as python module in a code that being executed by celery this is my code:

try:
                version = lastversion.latest(f'{org}/{lib}', output_format='dict', pre_ok=False)

                if version:
                    # Use the version
                else:
                    logger.error(f"Failed to fetch version for {org}/{lib}, got: {str(version)}")
            except Exception as e:
                logger.exception(f"An error occurred while trying to fetch version for {org}/{lib}", e)

I execute this code inside a loop that has around 45 iteration For some reason beyond my understanding from time to time the function returns None but when i look at my logs i see that the module in fact DID managed to get the last version of that packages that he then returns None for them:

It happens with SiliconLabs/uC-OS2 (but not only) When i run the same code in IDLE it works just fine

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

More logging for #44 — committed to dvershinin/lastversion by dvershinin 3 years ago
Graphql update; lazy detect repo name change when fetching the feed #44 — committed to dvershinin/lastversion by dvershinin 3 years ago

Most upvoted comments

C:>lastversion SiliconLabs/uC-OS

@IlanBeloglovsky it just looks like you forgot trailing 2 in SiliconLabs/uC-OS2, so that’s a project that doesn’t exist. Added check so it will raise BadProjectError for that case.

dvershinin on Feb 3, 2021

So that was all useful 😃

Note how the repo name is actually now weston-embedded/uC-OS2 and not SiliconLabs/uC-OS2 which you’re using. Normally there is no issue with it: GitHub always redirects to the new repo name in both the API, and any link in repository web UI (e.g. releases.atom is redirected).

But for whatever reason, GitHub is not giving you the redirect for releases.atom when requested from AWS. And gives just the 404. This fails the first and most efficient method. It’s an actual issue with GitHub servers not behaving consistently.

Now, the workaround I added is if it sees a 404 for the releases.atom, it will try to use the API (and hope that the redirect does happen there), to discover the new repo name and re-fetch the feed from the proper name URL.

The graphql issue is actual. The “tagger” exists only for annotated tags, and the other items returned by query which don’t have it represent a non-annotated tag. I mistakenly thought we shouldn’t bother with those and such only exist in old imported code (from the CVS), but it’s pretty common. Replaced with what seems to be a more reliable query found here. So the new logic is that we use actual tag (annotated) whenever available, and fallback to commit’s (non-annotated tag) date.

Please test again using latest commit, and if it’s all good will tag a new version.

dvershinin on Feb 2, 2021