do not use beta wheels when building a tag

Testing the tags against stable version will move the maintenance of keeping stables uptodate to the developers.

Probably we need to make sure that nightlies in the stable branch also uploads the new wheels.

Yes, but that will require a bit more work on bob.admin...

mentioned in commit 591e33e3

merged

In fact, I'm asking myself if we should do this... A stable wheel is not necessarily compiled against the latest available CI environment.

The whole thing may just crash.

OK, after thought, I agree we need a "stable" rebuild. We can achieve this by simply passing a variable when we trigger the nightly master build:

https://docs.gitlab.com/ce/ci/triggers/#pass-build-variables-to-a-trigger

In essence, we need then to trigger 2 builds - one that will build stable against stable, whereas another build that will build master against master. In order to implement this right on the nightlies:

1. A new function that determines what is the latest tag of a package. Use: http://stackoverflow.com/questions/26918785/how-can-i-retrieve-a-gitlab-project-tag-list-through-the-api. More info: https://docs.gitlab.com/ce/api/tags.html
2. A switch that will be based on the set variable to build master against master or stable against stable.

This variable should be automatically (by this package scripts) set if we're building a tag.

Another issue: inclusion in the nigthlies is not a guarantee the package will have a tag. So, there must be a fallback.

I think all the issues that you are mentioning can be fixed by just having a separate branch in nightlies (stable) and triggering that separately.

We can achieve this by simply passing a variable when we trigger the nightly master build:

Having a separate branch means we can have different behavior.

In essence, we need then to trigger 2 builds

One in master branch and one in stable branch. This is already setup.

A new function that determines what is the latest tag of a package.

You need to run git fetch anyway because the repo is cloned with --depth=1 option.

A switch that will be based on the set variable to build master against master or stable against stable.

A separate branch can have different logic.

inclusion in the nigthlies is not a guarantee the package will have a tag. So, there must be a fallback.

Just remove it from extra.txt in the stable branch.

And if you are wondering how can we maintain two branches in nightlies: cherry-pick

mentioned in issue #42 (closed)