GitLab now has support for subgroups, but Pages has not been updated to take account of this and Pages cannot be used at all with subgroups. This is an arbitrary limitation that keeps more users from being able to take advantage of using Pages.
Further details
Solution
Taking security and conflict possibilities into account, the best approach is: toplevel-group.gitlab.io/subgroup/project since this is the only variation we found that is guaranteed never to conflict.
We will add routing based on the above convention.
What does success look like, and how can we measure that?
Users are able to configure and deploy to GitLab pages for subgroup projects
Links / references
Documentation
We should describe the way this feature works on https://docs.gitlab.com/ee/administration/pages/. I'm not certain exactly which section it should go into, or if it should be its own section, but enabling pages on a subgroup and how the URL will work should be outlined.
@mydigitalself Pages-specific functionality is, but since Subgroups is ~Platform, I'd say making Subgroups work across the board (including with Pages) is ~Platform. We'd need to find a Go developer to work on it, but otherwise I think scheduling it as a ~Platform feature makes sense.
is worth mentioning that subgroup pages using the url format: http(s)://subgroup.group.gitlab.io/project would not be covered by a wildcard ssl on the primary domain so would make running over https problematic, you'd need to issue wildcard ssl's for all namespaces to cover their subgroups.
might need to look at using a format like: http(s)://group.gitlab.io/subgroup/project
that said, +1 for me on this as we've started using subgoups to organise things better and build documentation using pages
@gavtaylor In your example/suggestion: what would or should happen if your group has a project named foo-bar (with a page) and you try to create a subgroup also named foo-bar and try to publish the subgroup page?
We already have some awkwardness in that . is a valid character in namespaces:
Of course, SSL is broken for this Pages instance, for all the reasons stated before, but in addition, a subgroup of nick/thomas or thomas/nick will conflict with it, if we put the subgroup into DNS.
Looks like we're also affected by this in gitlab-ee (so not just ce).
Url that's in the settings (and honestly I think should say that way personally): https://parentgroup.gitlab.com/subgroup1/subgroup2/.../project/file.html
@morsik you are fortunate. I spent like a week trying to find out what was going on, before figuring out it was because of this issue. And it was more interesting due to I have this self-hosted GitLab CE. So, as @Leviathanone says… any milestones for this one?
what would be nice too is to set a base url for a subgroup so that gitlab.com/org/packages/package could be accessed from packages.org.com/package just like how gitlab.io works so that all new packages just work without going into the settings of each repo
I think in the interim, we should change the Settings->Pages text to indicate that it is not supported. Right now the text indicates that it should work. Have opened #34864 (closed) to track that.
Wouldn't scale it better with a path since the subgroups feature?
From the administrative perspective that would be quite easier. Yes, there is Let's Encrypt and yes, it is very easy to use and automate, but if you work in a company with a top-level wildcard certificate only, you have to mix up CAs which ends in a mess.
And if we think about multiple subgroups you will have a lot fun with yet.another.nested.subgroup.in.my.gitlab.io.
Maybe it is possible to switch between the current wildcard solution and a seperate domain/subdomain wich scales out to paths. So it would be possible to set pages.gitlab.com/group/subgroup/project.
@gavtaylor mentioned this also in his comment here.
I am currently not sure if it is possible to promote subgroups to groups or if this is planned. If so, we should keep in mind that you maybe have to create a new subdomain in that case.
But with both 'all path' and 'group with path' you have to make sure that the users will know the new address - so no difference here.
I actually believe it could be useful to have URI's as proposed in this ticket.
But I hope it could be OPTIONAL. I do not want stuff "as yet.another.nested.subgroup.in.my.gitlab.io" in all my projects.
The path method was what i was actually expecting, vs the subdomain. it would be far easier to implement in my opinion and it would be a lot simpler to manage one domain and one cert. And the last thing you want in security matters is complexity
Is there ANY way at all to get subgroups pages up and running? even if it a temporary fix until an update id be willing to try because my collective REALLY needs this feature :(
Unfortunately, doing something like subgroup.group.gitlab.io or sub.group.another.one.group.gitlab.io, etc. would require a wildcard certificate that could handle such subdomains, and at our company, it's a hard enough process getting a regular subdomain certificate so getting an approval to go nested would likely get declined (internally). I think the mentions in this ticket about subgroup.gitlab.io is the best proposed idea. From looking at the source code, it looks like a subgroup is literally just a group with a pointer to a parent, or something along those lines. If this is the case, I would doubt there would be any name conflicts - right?
I was under the impression that groups were unique in name. Didn't realize you could have two with the exact same name. They must be unique by full_path if that's the case?
If that's the case, then I think the only solution without having to butcher wildcard certificates would be group.gitlab.io/subgroup1/subgroup2/sub3/project or something...
Since the milestone for this is 3-6 months it maybe is a good idea to add a temporary notification on the "Pages settings"-page when trying to use Gitlab pages in a subgroup repo. I just spent some hours to figure out why it wasn't working as expected. Then I found out it was related to my repo which was in a subgroup...
Why don't we, for the time being, allow subgroup pages, with names being unique and completely independent from the group hierarchy. And if that name is already used elsewhere, then prevent that name from being used. That way, we can have a working subgroup pages system and devs can do stuff like creating lowersubgroup_subgroup_group.gitlab.io or so on, by using any other valid separator. It shouldn't be too hard to implement, right?
We are making progress in serving artifacts directly from GitLab Pages, at least, for %10.0. This is likely to form part of the solution, as it allows us to identify projects without ambiguity.
One option for serving subgroups in gitlab pages is to just drop any pretence of human readability and use namespace-#{id}.gitlab.io. Custom domains exist for people who want human-readable domains.
We could also specify that the lowest-numbered leaf namespace is an alias for the less-human domain. This should allow most existing users of gitlab.io, for instance, to keep using their accustomed name.
So say we have this hierarchy:
foo id=1 abar id=2 foo id=3 a (fork of foo/a)baz id=3 foo a (fork of foo/a) b id=13
foo.gitlab.io and namespace-1.gitlab.io are the same. If bar/foo wants a group namespace other than namespace-3.gitlab.io, they'd need to attach a custom domain to it.
A namespace like nick.thomas is still invalid, but I add a custom domain or visit namespace-{id}.gitlab.io instead.
We could even specify that the name be mangled to nick-thomas and for that to be valid if the nick-thomas ID is higher than the nick.thomas one.
Revisiting toplevel-group.gitlab.io/subgroup/subgroup/project for a moment...
I think this might actually be OK. Security is provided for because everyone in the top-level group has access to all child groups.
The fact that someone who's only a subgroup member can affect projects outside that subgroup is analogous to the fact that at the moment, someone who's only a project member can affect other projects in the same group, isn't it?
We don't worsen our position w/rt top-level groups that contain a ., but we don't improve it either. Subgroups that contain a . will work, though.
Subgroup and project paths aren't allowed to conflict, so there shouldn't be any issues there.
Afraid not. Labels can only be 63 characters long, while nesting can go 20 levels deep. Plus, you then introduce conflicts between group foo-bar and subgroup foo/bar.
At this point, I would take something, anything so long as this becomes a working feature, at least for now. For the time being, I would suggest we go with the unique id that @nick.thomas suggested, since that seems the less problematic and easiest to implement, as a stopgap if nothing else.
Scheduling is quite hard at the moment, since HTML artifacts viewer has higher priority, but if we manage to finish it early this can be the next iteration. Can you give me an idea of the effort needed?
@bikebilly it uses URLs like group.gitlab.io/-/subgroup/subgroup/project/-/artifacts/... to avoid shadowing actual group, subgroup or project pages.
The note was there because, earlier, I'd incorrectly assumed that html artifact view for subgroups would be broken until this issue is done, but it isn't.
I also have the same problem, that I submitted in issue #30548 (closed). The issue title was recently changed and I only now realized that subgroup pages were not available.
I think that would be useful to document this limitation in the current gitlab stable version for gitlab pages. Several months ago and releases behind, I run the CI and it deployed with success the pages. The only problem was with the provided url (error 404). That didn't allow me to understand that subgroups were not supported, since gitlab pages deploy was succeeded.
I read the suggestions and I would like to add the option for using domain name or virtual directory, such as:
4h lost as I installed 10.2 to use gitlab pages for artifacts (i do not need to use gitlab page for any other reason)
And now i end up here .. maybe someone can really point that subgroup are not supported in gitlab doc of artifacts w/ page.
I work on a large EE installation, and we were about to restructure all of our projects into group / subgroup structures. Just discovered this issue with our first project, and realise now that we can't do this (glad I found out before!!). A lot of our projects generate documentation using pages. Any chance of bumping up the time frame on a fix?
I like the simplicity of top-level-group.domain/sub1/sub2/project.
Hello,
recently I've working on setting up GitLab Pages for my company. Of course we use subgroups so such feature is highly recommended. Are there any news about how it's going on? Any word about release date?
I've been wondering about the progress. Is this considered at GitLab or not? Looking back, this feature is on demand on GitLab so I presume that we will see it, but when excatly?
@bikebilly This issue has been in milestones 3-6 months from now for over half a year, and over 7 releases in the current milestone. Further more it has 100 upvotes from the community.
However, it seems not have had much product love. Is there a way you could do that, and afterward schedule it to an actual release?
That said, new features in Pages have had a nasty habit of generating regressions for the past few releases, so we should bear that firmly in mind. Maybe we should include a set of gitlab-qa scenarios as a necessary part of the effort.
I scheduled this for %11.1, but I need confirmation by @ayufan and @nick.thomas that there is some capacity to work on it, since Pages requires specific skills and so the candidates are limited.
@bikebilly I can't think that far ahead at the moment but perhaps this would be a good first issue for the additional pages maintainer that was discussed in the 10.7 retrospective (/cc @ayufan)? That'd give us guaranteed capacity to work on it - we just need to find a willing vic^Wvolunteer :)
Sorry for the spam, but for anyone that is interested, I am working on a server that will use the GitLab api to serve up pages from sub groups. It should be done within the next two weeks.
@ayufan@nick.thomas@nolith I'd really love to see this feature done in %11.1, but I'm wondering if someone can work on it. As far as I know, the people with the right skills are already busy with other critical tasks.
@bikebilly I'm unsure what I'll be doing over the 11.1 release - in theory, the ~"GCP migration" will be coming to a close and I'll be reverting back to the platform team, but the finishing date for the migration is ncessarily uncertain.
Historically, I was split between platform and CI/CD - if @DouweM and @stanhu agree, I'd be happy to make this the first thing I do after the migration, which may or may not fit within 11.1
Just a heads up that this issue is plaguing a couple of very large, very important customers who have been asking for this to be fixed for 6-7 months now.
Let's see if @DouweM and @stanhu agree on your proposal, it would be awesome! Otherwise we'll figure out a different way or will wait for you until necessary
Hey guys, I wound up finishing my project sooner rather than later. I have it currently deployed internally for my company, so I consider it ready for prime-time.
@nick.thomas I think that's a reasonable proposal!
Because of the uncertainty around when the GCP Migration will be "finished", I'm going to assume you'll be unavailable for ~Platform work until that finishing date has actually passed, and I won't start asking you to work on specific ~Platform things until the kickoff of the next release after that date (probably %11.2), so all of %11.1 is basically yours to fill in :)
Thanks for the work on that solution @pauldotknopf! It's appreciated, although obviously, we still need to implement support for this in core so everyone can benefit :).
Thanks for clarifying @DouweM, I'll keep this one in mind then.
@nick.thomas Given toplevel.gitlab.io/foo/bar/baz, is it:
toplevel/foo(group)/bar(group)/baz(project)
toplevel/foo(project)/bar(dir)/baz(dir)
#33422 (closed) talks a fair bit about implementing access control with a proxy, but, for that to work, request URLs are the only hint for looking up project names. With #29767 (moved) (or similar), it would be possible to translate the current URLs into a project name and then make a single query to check for authorization.
With the current API and the proposed URLs, I can't think of an easy way to get project permissions from a URL:
I can't figure out the project id.
I can't query every possibility of the project id without protecting against things like /h/a/h/a/h/a/h/a/h/a/h/a/h/a/h/a/h/a/h/a x200.
I can't get a listing of public / internal projects because there are too many.
I can list a user's private projects and parse / pattern match the results, but it's way harder and less efficient than a simple translation with well known delimiters.
Someone's got _ as a namespace, you've used -, and . maps to the current directory. Is toplevel.gitlab.io/~/foo/bar/baz/~/qux a possibility if it simplifies #33422 (closed)? It keeps the translation predictable:
Disclaimer: I don’t really know what I’m talking about.
What if the pages server returns the project ID in a header? Could the
access control proxy send something like an OPTIONS preflight request, and
extract the project ID from that header?
@firelizzard Your reply helped me a ton and I think you're right. I don't care about the URLs. All I want is the Pages URI for the project. If I send an OPTIONSHEAD (I'd want to cache it) request to https://ryanjaeb.gitlab.io/foo/bar/baz/index.html, I want this custom header back if the project is foo:
I'd like to report another GitLab EE customer that would like to have this kind of feature.
Our developers have been waiting eagerly on this feature just to realize that we can not really use this since all our products are structured in (sub) groups. All the services that belong to a product are in the same (sub) group.
Gitlab decided to not provide plugins (like e.g. Jenkins) to support Code Coverage test results or other metrics, argumenting that this is user responsibility and can be published with Gitlab Pages perfectly fine.
However, now if you have a larger project and need the subgroup organization and those metrics, there's no support for gitlab pages to publish the reports.
We recently activated gitlab pages for our gitlab EE installation and just ran into the issue that pages are not beeing deployed, even though the pipeline succeeds and no errors are thrown.
Only after wasting too much time debugging did we find out that there is no support for gitlab pages for projects inside subgroups.
Seems we discussed/intended to add a notification about this in https://gitlab.com/gitlab-org/gitlab-ce/issues/30548#note_34493305. In the end, we opted to just remove the Pages menu item from the Settings tab for projects in a subgroup. It seems this is not clear enough to users that Pages are not supported in subgroups.
From the ticket:
Also; Why is this not documented anywhere? As there are no errors beeing thrown it is really hard to debug and i can imagine there are alot of people wasting alot of time on this. Currently the word subgroup is not even mentioned on the documentation page (and i would bet anywhere in the documentation about pages): https://docs.gitlab.com/ee/user/project/pages/ . I would suggest adding a warning about this.
The company I work for just (literally today) upgraded to Premium in order to be able to use the expanded functionality regarding issue boards so we can migrate away from Jira (as Gitlab advertises with quite clearly). We moved all of our application groups to one new parent group so we can have a single issue board for all our projects. As a result, every single Gitlab Pages URL suddenly stopped working because of this undocumented "feature" where subgroups are not supported.
We're really not happy about this. This has cost us a lot of time, resources and frustration thus far, since we basically had to move all of our projects back to the way they were because of this.
When can we expect this to be fixed, and why has this been on the backlog for over a year? This should be looked into right away, and not "soon".
At least fix your documentation or add some kind of warning!
@max.s1, would it help you to know that they are currently working on a completely new product called Meltano for data teams?
In all seriousness, GitLab needs to re-prioritize their work log. There is a current (IMO clear) perception that GitLab is skimming from feature to feature to check off marketing material check-boxes without focusing on the usability/bugs of the core product.
@max.s1, in the mean time, you could use my project here. It will give you support for sub-groups, at least until they implement this into the core product.
@max.s1 and @pauldotknopf - I understand the frustration here, but I want you to know that as the new PM for CI/CD this is a priority for me. It is being looked at for scheduling as soon as possible.
What about using emoji as an alternative to the . separator?
Only slightly joking, but if there are any other url safe ascii characters we don't allow in namespaces we'd be able to use them as a workaround.
Unfortunately a quick search discounts emoji unless we are happy with subgroup⚫my-group.gitlab.io appearing as http://xn--subgroupmy-group-fv9k.gitlab.io/ outside of safari, and most ascii characters would be percent encoded.
@nick.thomas What about https://subgroup~my-group.gitlab.io/ using ~ as the separator?
@jamedjo we very nearly used ~ as a separator in the online view of HTML artifacts feature. However, some web browsers simply don't support URLs where they appear in the domain, even though it's technically valid.
@nick.thomas My https://gitlab.com/gitlab-org/gitlab-ce/issues/30548#note_80754911 is a not an issue given !18589 (merged). To clarify, it would only be an issue if someone wanted to determine the project ID and had only the URL as a reference. For example, I was playing around with building a Caddy plugin as an access control proxy and, once subgroups are added, it would have become difficult to determine what's a project and what's a sub directory when the only info available is the request URL.
Properly integrated access control like !18589 (merged) is preferable and should have access to enough info that it doesn't need to be able to parse the URL to figure out a project name.
@johnypony3 this is obviously an important issue for the community and the product managers have set a milestone for this feature to be integrated into near-future releases. At the same time, we always welcome contributions and if you would like to submit a merge request, you can mention this issue and tag the appropriate product manager. =)
ive been through alot of these types of features where the community has
asked but the company not performed. sorry if its a but harsh but this sure
seems like a repeat of this.
@johnypony3 I understand that often sending in a feature request goes into some "invisible black hole", but at GitLab, we try to be as transparent as possible about our direction and what we're working on.
We appreciate the feedback we receive from the community, but we have a lot of feature requests (4829 open in CE, not including EE, runner, etc.), so our product managers do their best with the resources we currently have.
I know that doesn't necessarily help you get the features you want into GitLab, but that is also why we encourage merge requests from the wider community. Users who need a feature sooner than we can ship it can work with the team to get a merge request accepted and benefit the whole community.
We have a number of positions open in order to scale and make GitLab an even better product, so if you're interested or know anyone who fits the bill, please (have them) send in an application =)
In terms of timeline, if an issue has a milestone assigned, you will see it under the Milestone section on the right hand side of the issue:
You can also see all our milestones and click through to a specific set if you wish, such as the 11.4 milestone for a list of the issues the team is working on for the next release.
@johnypony3https://gitlab.com/johnypony3 I understand that often sending in a feature request goes into some "invisible black hole", but at GitLab, we try to be as transparent as possible about our direction and what we're working on.
I know that doesn't necessarily help you get the features you want into GitLab, but that is also why we encourage merge requests from the wider community. Users who need a feature sooner than we can ship it can work with the team to get a merge request accepted and benefit the whole community.
If someone is interested in working on this I'd be happy to sit down and have a chat with them and @nolith , our technical lead for pages. It's on our roadmap for 2019 but of course we always welcome contributions.
@nick.thomas One simple question: What depth of nested subgroups will be supported? Generally this shouldn't be constrained toplevel-group.gitlab.io/subgroup1/subgroup2/../subgroupN/project
Most use cases I have for pages from a project in a subgroup I would end up having a custom domain with anyway. From my understanding a CNAME record requires pointing to namespace.gitlab.io or an A to the gitlab pages server IP. I have not seen much talked about how this would affect domains. From my understanding there should not be anything blocking custom domains itself from working as it is. it seems to be more held up behind being bundled with the rest of pages needing a url schema for the hosted domain.
@jlenny The issue for this bug exists since 2017 Q1 and now the milestone has been set to 2019 Q4? The labels suggest this is a highly requested feature by Enterprise customers yet it keeps getting pushed from one milestone to the next and the next and so on.
At this point I think everyone just wants to see this fixed, as soon as possible, but, I think it would be very valuable to evaluate why the progress on this has been so slow and why the targeted release had to be changed 6 times.
@martijnrondeel I understand where you're coming from. We do prioritize items looking at demand from enterprise customers, and with other enterprise customer requested features along with other vision items we're delivering, and the resources available to the team, this was where this landed as we looked at the 2019 roadmap.
Things can always change, of course, and our desire is always to do everything as soon as possible - these highly upvoted items are always on my radar for opportunities to find a way to deliver if we get the opportunity. We also welcome community contributions, and access control for pages (also part of our 2019 vision) will be delivered next month thanks to a fantastic community contribution.
@jlenny As the TAM for a number of Enterprise customers and the fact that this issue has been on two of our Top 10 Lists from our Enterprise customers, I'd say this this is in high demand from our Enterprise customers.
Thanks @jwoods06 for confirming - sorry if it came across in my reply that I didn't think this was an issue that enterprise customers were looking for. That's of course not the case, and just to be super clear we aren't treating this as an item that people aren't interested in, or that isn't worth building. The 2019 vision (https://about.gitlab.com/direction/release) is filled with items that customers are looking for, sequenced out against the resources available to us.
To be sure, highly upvoted items like this one are something we're always on the lookout for a way to bring forward, and community contributions are also a great way to get these kinds of popular requests done.
This would also be beneficial for us within GitLab. We are starting to add a lot more frontend projects and it would be ideal to scope them to our frontend group within the gitlab-org group but we can't since we need gitlab pages for most of them. I'm starting to see a lot of bloat within our gitlab-org group because of this.
Of note, I would use this as an "enterprise customer" a lot for subgroups of gitlab-com.
Many GitLab teams and groups have separate top-level groups just to accomplish this, whereas it would be easier to manage the permissions model if they could be subgroups of gitlab-com. For example:
not sure who is prioritizing this stuff, but there is absolutely nothing in https://about.gitlab.com/direction/release/ or even in gitlab 11.x that is more critical than this. gitlab pages effectively doesn't even exist for us without a fix. i think this should be moved back to Q4 2018
I agree that every sub-group would be fine managing their own domain / pages config or something like using a sub-path approach would be fine too. This is something everyone really needs and we keep being told it would be looked at soon...
As another large EE customer (on-site install with users in the low thousands) I echo the sentiment expressed @martijnrondeel upthread.
It's not so much that we absolutely need specific features at a given date, but that pushing these milestones around seemingly at random makes us unable to plan things around GitLab, in this case we'd told internal users that wanted this that it was coming relatively soon, but that's not happening anymore.
@jlenny [...]"these highly upvoted items are always on my radar"[...]
My experience is that this priority system used by GitLab of upvotes is completely at odds with how to sensibly run Enterprise subscription accounts.
When some of us ask for features we sometimes have hundreds or thousands of paying users behind our request, but that just gets turned into a monolithic "customer" (or "customer+") label, saying that 1-2 customers wanted it.
Thanks so much for the open feedback everyone. After catching up with @nolith, based on the demand here we have found a way to bring this forward to %11.6.
I don't know how this is gonna be implemented but I want to make a suggestion that should be pretty easy to implement (teorically).
We have Currently the format group.gitlab.io and subgroups pages doesn't work mainly because we might have different (quite infinite) neasted groups an they might be n*subdomains. We must have something unique.
What about the id?
I would apply this to even to the top level group.
So instead of group.gitlab.io/project we'll have {group_id}.gitlab.io/project or why not... Even just {project_id}.gitlab.io.
I've read alot on this discussion and I guess most of people want this feature implemented asap and forget about the nice named subdomain. Half of us might want to put this in a cname to easily setup a nice domain.
Note: using gitlab project IDs as subdomain might cause problems since there might be a project called like a project id... Rare but possible. Ya? This is solvable by changing gitlab.io to a new one for this feature or just managing who gets priority "string" or "id".
@FranklinYu I agree that seems like a clean and simple solution that would work for everyone.
What about also "optionally" allowing sub-groups to set their own direct domain for use cases like pointing a cname at it or other ideas? Couldn't hurt?
@daquino As explained above, this may create conflict because . is allowed in username. If there is a subgroup called foo within bar group, I can create an account foo.bar to spoof Pages in that group.
its great to see traction on this issue, but there doesnt seem to be much conversation on how custom domains will work with this, we wont be able to assign a cname to a subfolder system like the one proposed, is the idea we point dns to the parent groups subdomain and let gitlab route it based on what project it has the custom domain registered against?
@gavtaylor Very reasonable use case. I think we can have namespace-#{sub_group_id}.gitlab.io suggested by https://gitlab.com/gitlab-org/gitlab-ce/issues/30548#note_40906461; for example if your sub-group has ID 42, you will configure a CNAME from my-page.example.com. to namespace-42.gitlab.io. I personally prefer namespace-#{sub_group_id}.gitlab-pages.io to avoid collision, because I believe namespace-x is a valid username.
@FranklinYu Mankind has created DNS to get rid of IDs and numbers like IPs. Don't go back into the stone age of the Internet and introduce IDs into the URLs.
We want to store our product documentations on that pages. Thus, these should have memorialize URLs!
@paebbelsnamespace-42.gitlab.io is only intende for folks that want custom domains, and it’s hidden behind CNAME. For most user https://foo.gitlab.io/sub/proj/ just works (and you get TLS certificate for free). I don’t see the issue here; in the proposal we are exactly making full use of DNS to avoid memorizing ID.
Custom domains, with CNAME, will work the same as today, removing the need to use longer URL.
If your gitlab pages serves by default my-gitlab-pages.com, and you have ProjectA nested in group0, subgroup1, subgroup2; then your pages will be available as http://group0.my-gitlab-pages.com/subgroup1/subgroup2/ProjectA
If you add project-A.com as custom domain fot the project it will also be available at http://project-A.com
https://gitlab.com/gitlab-org/gitlab-ce/issues/30548#note_40908100 describes projects that belong to subgroups (ex: toplevel-group.gitlab.io/subgroup/subgroup/project). What about enabling pages directly on a subgroup (ex: toplevel-group.gitlab.io/subgroup/subgroup)?
Currently it's possible to use pages on top level groups by using the correct naming convention for a project name (ex: toplevel-group.gitlab.io). That won't work for subgroups though since (ex:) toplevel-group/subgroup.gitlab.io is not a valid project name.
#29963 (moved)
i think this is related also.
i wouldn't mind being able to have a path name of https://pages.gitlab.example.com/<group name>/project/html/index.html
It appears that this was missed for code freeze today in %11.6, so setting milestone to %11.7 for now. If the remaining work will not fit in %11.7 please let me know. cc @jhampton@erushton@nolith
@nick.thomas + @jlenny, any chance we could get a status report re: what's going on here and some color around why this suddenly slipped the milestone?
@knksmith57 I'm sorry but it slipped the milestone because the feature freeze is on the 7th and we had to prioritize 2 security fixes that made this feature slip.
The code is ready and under review, but wasn't completely reviewed in time for the feature freeze.
I understand that this can be disappointing, but a milestone is not a promise; we always plan our releases ambitiously and it's not out of the question for something to be missed. This has remained a high priority for us and we're going to complete it as soon as we can; it's not moving because we don't think it's important.
But there is a problem. Our is a private organisation on gitlab. And the gitlab pages for the sub-project is public. Anyone can access it.
Given the company organisation, we still cannot go ahead and use this feature. Which makes me sad :(
My self-hosted GitLab Omnibus instance v12.2.5 (09f8edbc) has managed to deploy the artifacts to /var/opt/gitlab/gitlab-rails/shared/pages/group/subgroup/project/public/ and in the web interface at https://gitlab.domain/group/subgroup/project/pages it also says
but opening that domain in a browser returns a 404 page and gitlab-ctl tail nginx says 404 as well. What is going on here?
The instance has been installed as v8.x and then continuously updated until today. Is it possible that some leftover configuration is in the way somewhere?
same problem with gitlab.com group/subgroup/project. Tried both with custom domain (with successfully validated TXT rule but unknown error with lets encrypt) and with no domain, expecting it to be visible at group.gitlab.io/subgroup/project.
If i browse the artifact and open the index.html manually it works (because references to other files uch as openapi.yaml are relative to current location).
https://<group>.gitlab.io/-/<subgroup>/<project>/-/jobs/<jobid>/artifacts/public/index.html
Am I still missing anything? the lack of debugging information is driving mi crazy.