Changes to artifact proxy

Per https://gitlab.com/gitlab-org/gitlab-ce/issues/34102#note_41761135

• group.gitlab.io/subgroup/project/-/jobs/11/artifacts/aaa.txt

Our issue is that we can't come up with a domain label to embed the project ID and job ID into that both:

• Is an invalid group name
• Works in browsers

artifact~1~2.gitlab.io was awesome, but only worked in safari in the end(!)

We haven't made a release with this code in yet, so we're going to quickly change the scheme so artifacts are served as a part of the relevant project site instead:

artifacts~1~2.gitlab.io/index.html for group/project becomes group.gitlab.io/project/-/jobs/2/index.html

The API will use group%2Fproject as the project ID. Fortunately, this already works 🗡

We will need to take special care for groups with a . in them, e.g., nick.thomas.gitlab.io/project/-/...

When enabled, there is potential for the reserved path to conflict with files in the pages site. We should reduce the scope of that as much as possible. Things to check:

• Do we shadow files in the pages site for group.gitlab.io ?
• Do we shadow files in the pages site for group.gitlab.io/project ?
• Do we shadow project names in the group?

Pages doesn't support subgroups yet. If we can include subgroup support in this feature, great. Otherwise, it will have to wait until all of pages supports subgroups.

mentioned in merge request !46 (merged)

I've gone for group.gitlab.io/subgroup1/subgroup2/-/project/jobs/1/artifacts/index.html

This shadows the project name, or the subgroup names, in the pages site for group.gitlab.io - but project pages already shadow group pages, so this isn't a big deal.

Using this scheme (rather than, say, group.gitlab.io/project/-/jobs/1/artifacts/index.html means that we cannot shadow files in the pages site for group.gitlab.io/project.

Also using this scheme, - is an invalid project name so we'll never shadow files for that project.

/cc @ayufan

mentioned in merge request omnibus-gitlab!1919 (merged)

But technically this is also slightly confusing, as today your project page is:

- group.gitlab.io/myhomepage/index.html

And now for artifacts we use:

- group.gitlab.io/-/myhomepage/jobs/1/artifacts/index.html

This makes it even more confusing, as when you navigate to gitlab you get:

- gitlab.com/myhomepage/-/jobs/1/artifacts/file/index.html

I understand the argument of shadowing -, as a problem, but I also wonder if this is really a problem, because if we use: ...io/-/ we also can shadow some valid path, so technically your proposition from https://gitlab.com/gitlab-org/gitlab-pages/merge_requests/46#note_41898596 (the group.gitlab.io/-/subgroup/project/-/jobs/1/artifacts/index.html) have the advantage of us introducing a top-level /-/ to be handled differently, and we could technically catch everything that starts with that prefix and try to parse URL, and if not, return 404 always.

Given the, what I like with that preference:

1. group.gitlab.io/-/subgroup/project/-/jobs/1/artifacts/index.html
2. group.gitlab.io/subgroup/project/-/jobs/11/artifacts/aaa.txt

I can live with 2. I would consider noting today that this is BETA, and the path is subject to change if we consider it to not be right. This may be needed as we start doing OAuth2, and other improvements. I just hate now that we are changing that over-and-over again :) So, please decide what is the best, I'm fine with either 1. or 2.

added In review label

OK, I'll do group.gitlab.io/-/subgroup/project/-/jobs/1/artifacts/index.html - it should be a small, quick change :)

closed via merge request !46 (merged)