I am using an image that’s stored in our gitlab project’s registry: gitlab-registry.cern.ch/atlas-phys/exot/ueh/exot-2017-19/dhnlalgorithm:master-1be5c586 On my local machine I’m able to authenticate via eval "$(recast auth setup -a $RECAST_USER -a $RECAST_PASS -a $RECAST_TOKEN -a default)" and then pull/run using that image with no problem. However when I do the same on a test job via CI I get the following error:
2021-10-01 17:52:18,269 | pack.packtivity_sync | ERROR | subprocess failed. code: 1, command docker pull gitlab-registry.cern.ch/atlas-phys/exot/ueh/exot-2017-19/dhnlalgorithm:master-1be5c586
Which seems to mean that I haven’t properly logged in, though I do get Login Succeeded earlier in the pipeline. Here is the failing pipeline: Pipeline
Is it because the RECAST_USER, RECAST_PASS, RECAST_TOKEN are different in the CI job and therefore don’t have access to our project’s registry? How would you recommend I fix this?
1 Like
I think I’ve found the solution here. The repository where the registry is stored is set to private so unauthorized users cannot pull the images.
To resolve this the user recast must be added with at least reporter permissions to the repository.
[note: this is contrary to the current documentation which says that the recastat user is sufficient for reading registries]
1 Like
Your project will have access to the global CI variables RECAST_USER, RECAST_PASS and RECAST_TOKEN for the recast-atlas service account. This account can pull images from all gitlab registries with CERN internal permissions, and has access to all files stored under /eos/project/r/recast/atlas. If this account is sufficient for your current needs, you can also skip step 2 (setting CI variables). Keep in mind that eventually your workflow should be able to run using the recast-atlas service account.
@rnewhous This section in the docs is referring to the project in the recast-atlas · GitLab group, where @recast has Owner permissions already
But as gitlab-registry.cern.ch/atlas-phys/exot/ueh/exot-2017-19/dhnlalgorithm is in a separate area of GitLab, @recast doesn’t know about it and so doesn’t have permissions. So the addition of @recast with minimal reporter permissions is just so that it has visibility.
This can get clarified in the docs for sure though! I’ve filed it as Issue #8 for the docs.
1 Like
