container registry tags expect OCI image configs to have `created` field
Summary
OCI images that do not include a created date cause the the registry UI to display: No tags in Container Registry for this container image. and Something went wrong while fetching the registry list.
Steps to reproduce
(How one can reproduce the issue - this is very important) *requires helm v3: * https://helm.sh/docs/intro/install/
# helm registry login --password "$(secret-tool lookup username_value tobias.wolf@example.com)" -u tobias.wolf@example.com gitlab.example.com:5005
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login succeeded
# helm create foo
Creating foo
# helm chart save foo gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1
Name: foo
Version: 0.1.0
Meta: sha256:42603b382336019d658ec8c0c71c57be421dc49a471ce6c6b776d7834e54cbec
Content: sha256:bfc11b014315e14f4191ff0cd53a7f9158db9013722c33919f566ae9d69b8ef1
0.0.1: saved
# helm chart push gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1
The push refers to repository [gitlab.example.com:5005/tobias.wolf/build-test/helm/foo]
Name: foo
Version: 0.1.0
Meta: sha256:42603b382336019d658ec8c0c71c57be421dc49a471ce6c6b776d7834e54cbec
Content: sha256:bfc11b014315e14f4191ff0cd53a7f9158db9013722c33919f566ae9d69b8ef1
0.0.1: pushed to remote (2 layers, 2.3 KiB total)
# rm -rf foo
# helm chart remove gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1
0.0.1: removed
# helm chart list
REF NAME VERSION DIGEST SIZE CREATED
# helm chart pull gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1
0.0.1: Pulling from gitlab.example.com:5005/tobias.wolf/build-test/helm/foo
Name: foo
Version: 0.1.0
Meta: sha256:42603b382336019d658ec8c0c71c57be421dc49a471ce6c6b776d7834e54cbec
Content: sha256:bfc11b014315e14f4191ff0cd53a7f9158db9013722c33919f566ae9d69b8ef1
Status: Chart is up to date for gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1
# helm chart list
REF NAME VERSION DIGEST SIZE CREATED
gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1 foo 0.1.0 bfc11b0 2.2 KiB 37 minutes
# helm chart export gitlab.example.com:5005/tobias.wolf/build-test/helm/foo:0.0.1
Name: foo
Version: 0.1.0
Meta: sha256:42603b382336019d658ec8c0c71c57be421dc49a471ce6c6b776d7834e54cbec
Content: sha256:bfc11b014315e14f4191ff0cd53a7f9158db9013722c33919f566ae9d69b8ef1
Exported to foo/
# find foo
foo
foo/.helmignore
foo/charts
foo/templates
foo/templates/service.yaml
foo/templates/ingress.yaml
foo/templates/deployment.yaml
foo/templates/_helpers.tpl
foo/templates/NOTES.txt
foo/values.yaml
foo/Chart.yaml
What is the current bug behavior?
Discussion here: #30669 (comment 244888846)
What is the expected correct behavior?
(What you should see instead)
Relevant logs and/or screenshots
Completed 500 Internal Server Error in 25ms (ActiveRecord: 1.3ms | Elasticsearch: 0.0ms)
ArgumentError - invalid date:
lib/container_registry/tag.rb:85:in `block in created_at'
lib/gitlab/utils/strong_memoize.rb:30:in `strong_memoize'
lib/container_registry/tag.rb:84:in `created_at'
app/serializers/base_serializer.rb:16:in `represent'
app/serializers/container_tags_serializer.rb:17:in `represent'
app/controllers/projects/registry/tags_controller.rb:17:in `block (2 levels) in index'
app/controllers/projects/registry/tags_controller.rb:12:in `index'
ee/lib/gitlab/ip_address_state.rb:10:in `with'
ee/app/controllers/ee/application_controller.rb:43:in `set_current_ip_address'
lib/gitlab/session.rb:11:in `with_session'
app/controllers/application_controller.rb:450:in `set_session_storage'
lib/gitlab/i18n.rb:55:in `with_locale'
lib/gitlab/i18n.rb:61:in `with_user_locale'
app/controllers/application_controller.rb:444:in `set_locale'
lib/gitlab/middleware/rails_queue_duration.rb:27:in `call'
lib/gitlab/metrics/rack_middleware.rb:17:in `block in call'
lib/gitlab/metrics/transaction.rb:62:in `run'
lib/gitlab/metrics/rack_middleware.rb:17:in `call'
lib/gitlab/request_profiler/middleware.rb:17:in `call'
lib/gitlab/query_limiting/middleware.rb:17:in `block in call'
lib/gitlab/query_limiting/transaction.rb:39:in `run'
lib/gitlab/query_limiting/middleware.rb:16:in `call'
ee/lib/gitlab/jira/middleware.rb:19:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/correlation_id.rb:16:in `block in call'
lib/gitlab/middleware/correlation_id.rb:15:in `call'
lib/gitlab/middleware/multipart.rb:117:in `call'
lib/gitlab/middleware/read_only/controller.rb:48:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:32:in `call'
config/initializers/fix_local_cache_middleware.rb:9:in `call'
lib/gitlab/middleware/static.rb:11:in `call'
lib/gitlab/webpack/dev_server_middleware.rb:27:in `perform_request'
lib/gitlab/metrics/requests_rack_middleware.rb:49:in `call'
lib/gitlab/middleware/release_env.rb:12:in `call'
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:env:info)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)(we will only investigate if the tests are passing)
Possible fixes
https://gitlab.com/gitlab-org/gitlab/blob/master/lib/container_registry/tag.rb#L85
This should either fallback to a default date or different mediatypes need to handled separatly