## Why are we doing this work This issue describes the ~workhorse work needed to deliver https://gitlab.com/groups/gitlab-org/-/epics/6396. ## Relevant links * [Parent Issue](https://gitlab.com/groups/gitlab-org/-/epics/63968) * [Rails counterpart issue](https://gitlab.com/gitlab-org/gitlab/-/issues/335560) * [Sequence diagram](https://gitlab.com/gitlab-org/gitlab/-/issues/11548#note_617440351) * [Discussion around possible approaches](https://www.youtube.com/watch?v=WmBibT9oQms) ## Possible approaches There are a two possible approaches as [described in this comment](https://gitlab.com/gitlab-org/gitlab/-/issues/335563#note_638336638). For future features using this need of "download and cache from an external url" will need to implement the following: ### Option 1: Using a response header * the rails that returns the new response header * the `/authorize` rails endpoint * the upload rails endpoint ### Option 2: Using a route handler * the `/authorize` rails endpoint * the upload rails endpoint * the new route in workhorse router ## Implementation plan The items below only describes the route handler approach, the response header approach has not been broken out. Both approaches should be evaluated before choosing the best one to solve this problem. * [ ] Add the [blob route](https://gitlab.com/gitlab-org/gitlab/-/blob/e411f3782b55e9689dc3fdf5540dbc5f9f4a9e1f/config/routes/group.rb#L147) to the upstream routes to be intercepted. * [ ] Update the response to the `/authorize` request to accept a json payload with fields (URL and token) for requesting an image from an external registry. * [ ] Use the returned URL and token to request the blob and upload it to the configured file storage system. * [ ] Allow workhorse to then follow the existing logic to return the file metadata back to rails to complete the originally received request to download the blob. * [ ] Return the blob file