docker images "latest" and "develop" are old

[Vincent Delecroix]

Dear all,

According to the page [docker] the images with tag "latest" and
"develop" are supposed to be the latest stable and development
versions. However sagemath/sagemath-dev:latest is stuck at 8.7
while 8.8 is released since July 7th (and the corresponding
docker image is available on docker hub). Similarly,
sagemath/sagemath-dev:develop is 8.8.beta5 while we are now
at 8.9.beta3 (8.9.beta2 is available on docker but not
8.9.beta3).

Shouldn't "latest" and "develop" be automatically updated?

[docker] https://hub.docker.com/u/sagemath/sagemath

Vincent

[E. Madison Bray]

On Thu, Jul 25, 2019 at 10:49 PM Vincent Delecroix

According to one of the build scripts [1], if the "master" branch is
built, it will be tagged as "latest". I'm not sure about "develop".
Apparently, although the build for the 8.8 *tag* completed
successfully [2], the one for "master" (at 8.8) failed sort of
randomly [3], due to a problem we've been seeing where `make` is
taking longer and longer (and longer than it should) so the build
times out. Need to investigate why it's taking so much longer.

In general, it would certainly be welcome to have more volunteers
monitoring and debugging issues with the CI pipeline, since getting
this working smoothly would be a huge benefit. But we haven't had
enough resources or people looking at it...

[1] https://gitlab.com/sagemath/sage/blob/b5c9cf037cbce672101725f269470135b9b2c5c4/.ci/update-env.sh#L37
[2] https://gitlab.com/sagemath/sage/pipelines/68209174
[3] https://gitlab.com/sagemath/sage/pipelines/68212724

[Markus Wageringel]

There also appears to be a problem with the credentials, causing the last step, pushing the image to DockerHub, to silently fail. For example, this is the log for the last run on the develop branch [1], which last ran for 8.8.rc1.

$ sh .ci/push-dockerhub.sh sagemath
+ sh .ci/push-dockerhub.sh sagemath
+ '[' -z develop ]
+ '[' -z  -o -z  ]
+ echo 'DOCKER_USER/SECRET_DOCKER_PASS variables have not been configured in your Continuous Integration setup. Not pushing built images to Docker Hub.'
DOCKER_USER/SECRET_DOCKER_PASS variables have not been configured in your Continuous Integration setup. Not pushing built images to Docker Hub.
Job succeeded

I am not sure why this has not run for any more recent updates to the develop branch, though. The sagemath:develop image at [2] is up to date at least. Perhaps, the develop branch in the gitlab mirror just does not get updated regularly.

[1] https://gitlab.com/sagemath/sage/-/jobs/231098209

[2] https://gitlab.com/sagemath/dev/trac/container_registry

[Julian Rüth]

Hi Markus,

Sorry, I had missed this discussion initially. The credentials for docker hub are protected secrets in GitLab CI. They are only provided to protected branches and tags. All tags are protected so they were correctly uploaded to Docker Hub. However, as I wrote on another thread, the branch were unprotected (probably because somebody wanted to restart the pipelines manually?) so they did not receive the secrets and (as you found) were missing the credentials to upload. It seems to work again now.

julian

[E. Madison Bray]

On Thu, Aug 1, 2019 at 7:09 PM Julian Rüth <julian...@fsfe.org> wrote:
>
> Hi Markus,
>
> Sorry, I had missed this discussion initially. The credentials for docker hub are protected secrets in GitLab CI. They are only provided to protected branches and tags. All tags are protected so they were correctly uploaded to Docker Hub. However, as I wrote on another thread, the branch were unprotected (probably because somebody wanted to restart the pipelines manually?) so they did not receive the secrets and (as you found) were missing the credentials to upload. It seems to work again now.

Wow--do I understand you correctly that, if a branch is marked
"unprotected" , GitLab won't receive the secrets credentials? And yet
the only way to manually restart a pipeline is to "unprotect" the
branch (which I did, as you say, in order to restart)?

I understand the idea behind not passing secrets to builds of
unprotected branches. These two cases seem to be at odds with each
other: How are you supposed restart a pipeline for a protected branch
if it fails for external reasons?

I think we should probably open an issue with GitLab about this. It
seems like an impossible bind otherwise...

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/13dadffa-c0a0-44ed-881c-ced687209b90%40googlegroups.com.

[Julian Rüth]

Hi Erik,

I think this is not a problem on GitLab anymore. I can restart protected jobs at least, so probably also entire pipelines.

[E. Madison Bray]

On Fri, Aug 2, 2019 at 5:27 PM Julian Rüth <julian...@fsfe.org> wrote:
>
> Hi Erik,
>
> I think this is not a problem on GitLab anymore. I can restart protected jobs at least, so probably also entire pipelines.

I just noticed that as well.  That's good news. I tried to find some upstream issue about it just out of curiosity as to exactly what changed but I couldn't find it. 

Nevertheless, it seems as long as you have push permissions to a branch you can also retry a pipeline on that branch, which I'd have assumed all along would seem reasonable... 

> On Friday, August 2, 2019 at 11:14:24 AM UTC+2, E. Madison Bray wrote:
>>
>> Wow--do I understand you correctly that, if a branch is marked
>> "unprotected" , GitLab won't receive the secrets credentials?  And yet
>> the only way to manually restart a pipeline is to "unprotect" the
>> branch (which I did, as you say, in order to restart)?
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/b845cefb-67a8-4c01-be7b-ce0e4b3b0227%40googlegroups.com.