First-level repository names are not handled correctly
Summary
First-level repository names are not handled correctly. When gitlab attempts to load registry tab UI for a project it queries the registry for tags for a zero-level repository name only, even if first-level repository image names are present. i.e., GET /v2/group-name/project-name/tags/list
instead of GET /v2/group-name/project-name/image-name/tags/list
Steps to reproduce
Registry configuration
registry_external_url 'http://<registry-domain-name>:5000'
registry['storage'] = {
's3' => {
'accesskey' => '<access-key>',
'secretkey' => '<secret-key>',
'region' => '<region>',
'bucket' => '<bucket>'
}
}
(I realize registry['storage']
may not be necessary, but the bug occurs with or without it set)
Docker-Compose (used to spin up registry)
registry:
restart: always
image: registry:2
ports:
- 5000:5000
environment:
- REGISTRY_STORAGE=s3
- REGISTRY_STORAGE_S3_REGION=<bucket-region>
- REGISTRY_STORAGE_S3_BUCKET=<bucket-name>
- REGISTRY_STORAGE_S3_ACCESSKEY=<access-key>
- REGISTRY_STORAGE_S3_SECRETKEY=<secret-key>
- REGISTRY_STORAGE_S3_ROOTDIRECTORY=/images
(rootdirectory is optional - bug occurs with or without it set)
Versions
GitLab 9.1.2
GitLab Shell 5.0.2
GitLab Workhorse v1.4.3
GitLab API v4
Git 2.11.1
Ruby 2.3.3p222
Rails 4.2.8
postgresql 9.6.1
docker client/server 17.03.1-ce
Steps
- Ensure docker daemon is started with
--insecure-registry <registry-domain-name:5000>
set. This is how the bug was produced. However, the bug has not been tested on a TLS configured registry, so it might occur in that use case as well. docker-compose up -d
gitlabctl-reconfigure | gitlabctl-restart
- Create new group and project (not necessary to reproduce, but easier to debug)
-
docker build -t <registry-domain-name>:5000/group-name/project-name/image-name .
# build docker image with tag specified in project's registry tab UI -
docker push <registry-domain-name>:5000/group-name/project-name1/image
# push built docker image as specified in project's registry tab UI - Navigate to project's registry tab UI - no images will be listed.
What is the current bug behavior?
When the gitlab registry tab UI is loaded for a project, the gitlab client calls the docker api endpoint for tags on a zero-level repository name only, instead of calling the tags endpoint for each image in a first-level repository name only.
Example, when registry tab UI is opened after the above steps (from docker registry logs):
time="2017-05-04T18:51:01Z" level=error msg="response completed with error" err.code="name unknown" err.detail=map[name:group-name/project-name] err.message="repository name not known to registry" go.version=go1.7.3 http.request.host="XXX" http.request.id=XXX http.request.method=GET http.request.remoteaddr="XXX" http.request.uri="/v2/group-name/project-name/tags/list" http.request.useragent="Faraday v0.11.0" http.response.contenttype="application/json; charset=utf-8" http.response.duration=30.264883ms http.response.status=404 http.response.written=131 instance.id=XXX vars.name="group-name/project-name" version=v2.6.1
172.17.0.1 - - [04/May/2017:18:51:01 +0000] "GET /v2/group-name/project-name/tags/list HTTP/1.1" 404 131 "" "Faraday v0.11.0"
Additionally, the gitlab logs show a 200 for the failed request
Started GET "/group-name/project-name/container_registry" for 67.79.201.170 at 2017-05-04 14:51:01 -0400
Processing by Projects::Registry::RepositoriesController#index as HTML
Parameters: {"namespace_id"=>"group-name", "project_id"=>"project-name"}
Completed 200 OK in 92ms (Views: 23.5ms | ActiveRecord: 5.1ms)
StuckCiJobsWorker: Cleaning stuck builds
What is the expected correct behavior?
The gitlab client should attempt to call the v2/<image-name>/tags/list
endpoint for all images in a project, up to a first-level name. <registry-domain-name>:5000/group-name/image-name
and <registry-domain-name>:5000/group-name/product-name/image-name
should both be supported, as defined in https://gitlab.com/gitlab-org/gitlab-ce/issues/17801
Additionally, if the call into the docker registry is returning a 404, that error should be propagated up into the gitlab logs and UI.
Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output, logs, and code as it's very hard to read otherwise.)
Output of checks
(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
Results of GitLab environment info
System information System: Current User: git Using RVM: no Ruby Version: 2.3.3p222 Gem Version: 2.6.6 Bundler Version:1.13.7 Rake Version: 10.5.0 Redis Version: 3.2.5 Git Version: 2.11.1 Sidekiq Version:4.2.7 GitLab information Version: 9.1.2 Revision: df1403f Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: postgresql URL: <redacted> HTTP Clone URL: <redacted>/some-group/some-project.git SSH Clone URL: git@e<redacted>:some-group/some-project.git Using LDAP: no Using Omniauth: no GitLab Shell Version: 5.0.2 Repository storage paths: - default: /var/opt/gitlab/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Checking GitLab Shell ... GitLab Shell version >= 5.0.2 ? ... OK (5.0.2) Repo base directory exists? default... yes Repo storage directories are symlinks? default... no Repo paths owned by git:git? default... yes Repo paths access is drwxrws---? default... yes hooks directories in repos are links: ... 2/1 ... repository is empty 3/4 ... repository is empty Running /opt/gitlab/embedded/service/gitlab-shell/bin/check Check GitLab API access: OK Access to /var/opt/gitlab/.ssh/authorized_keys: OK Send ping to redis server: OK gitlab-shell self-check successful Checking GitLab Shell ... Finished Checking Sidekiq ... Running? ... yes Number of Sidekiq processes ... 1 Checking Sidekiq ... Finished Checking Reply by email ... Reply by email is disabled in config/gitlab.yml Checking Reply by email ... Finished Checking LDAP ... LDAP is disabled in config/gitlab.yml Checking LDAP ... Finished Checking GitLab ... Git configured with autocrlf=input? ... yes Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config outdated? ... no Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory setup correctly? ... yes Init script exists? ... skipped (omnibus-gitlab has no init script) Init script up-to-date? ... skipped (omnibus-gitlab has no init script) projects have namespace: ... 2/1 ... yes 3/4 ... yes Redis version >= 2.8.0? ... yes Ruby version >= 2.1.0 ? ... yes (2.3.3) Your git bin path is "/opt/gitlab/embedded/bin/git" Git version >= 2.7.3 ? ... yes (2.11.1) Active users: 1 Checking GitLab ... Finished
Possible fixes
The expected behavior for this feature works correctly on gitlab.com
. I don't know what registry technology or configuration is being used for gitlab, but if it differs from our setup of gitlab -> external docker distribute registry -> s3
, then a great place to start would be at that difference.