1

Question

I have a GitLab repo XXX/website-www which contains code to generate a static website.

I am using GitLab CI for continuous integration/deployment.

For now, I have decided to use GitLab pages to host my static website. This could easily change in the future.

I found this simple configuration that I can add to my .gitlab-ci.yml file:

pages:
  stage: deploy
  script:
  - <...>
  artifacts:
    paths:
    - <static_website_directory>
  only:
  - master

This works nicely, but has one issue. The GitLab pages url is now XXX.gitlab.io/website-www.

I need to be able to access this website from a custom domain, and from what I know, this can't be done with the above URL.

I need to have something like XXX-website-www.gitlab.io.

Possible solutions

1) One way to obtain the url I need is by creating a a group named XXX-website-www, and inside, a repo named XXX-website-www.gitlab.io.

This has a couple of problems:

  1. I have to create a brand new namespace for this website, which is separate from my main group namespace.
  2. As I said above, I could easily switch from GitLab pages to another static website provider at any stage and vice versa. Now my group/project names have to change just to allow for GitLab pages to function.

2) Another solution would be to do repo mirroring. I would mirror XXX-website-www/XXX-website-www.gitlab.io from XXX/website-www, but I'm not even sure if you can mirror from another gitlab repo.

This sadly has another problem: the continuous integration will fail on the XXX/website-www repo.

How else can I achieve this?

3) Another solution would be to create a separate XXX-website-www/XXX-website-www.gitlab.io repo alongside XXX/website-www.

I would change the continuous integration for XXX/website-www to do a direct git add/commit/push to XXX-website-www/XXX-website-www.gitlab.io.

I would then do an initial commit to XXX-website-www/XXX-website.www.gitlab.io with GitLab pages CI.

This is quite a hassel, and still has the problem of number 1 above. It also seems messy working with git inside CI.

David Callanan
  • 5,601
  • 7
  • 63
  • 105

1 Answers1

1

Another solution would be to create a separate XXX-website-www/XXX-website-www.gitlab.io repo alongside XXX/website-www.

I would change the continuous integration for XXX/website-www to do a direct git add/commit/push to XXX-website-www/XXX-website-www.gitlab.io.

Well... you could reference XXX-website-www/XXX-website-www.gitlab.io as a submodule (displayed as a subfolder) in XXX/website.

Everything could be done, in the CI steps, within XXX/website which would checkout XXX-website-www/XXX-website-www.gitlab.io in its associated subfolder.
Add/commit/push can be done in that subfolder, provided a similar add/commit and push is done in its parent repo XXX/website

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Is it also necessary to add/commit/push in `XXX/website` when deploying? I want to avoid CI to be making changes to the master branch of `XXX/website` when deploying. – David Callanan Jul 31 '19 at 10:01
  • @DavidCallanan If `XXX/website` is the parent repository of a submodule, and said submodule does change, then yes: add commit and push is needed at the parent repository as well. – VonC Jul 31 '19 at 10:20
  • Ok thanks, I think I'll just clone, add, commit and push and not bother with a submodule. To me it doesn't make sense that the source repo has to update whenever the deploy repo is deployed (commited to), and therefore it doesn't make sense to use submodules. – David Callanan Jul 31 '19 at 10:27
  • @DavidCallanan It is more to keep a strong link between the parent repo and its submodule version, in order to be able to get back to the exact state (in the past) of said parent repo (referencing the right version of the submodule) – VonC Jul 31 '19 at 10:47
  • That actually makes a lot of sense! I never thought of that – David Callanan Jul 31 '19 at 11:12
  • @DavidCallanan Yes, I described that in 2009 in "True Nature of a Submodule": https://stackoverflow.com/a/1979194/6309 – VonC Jul 31 '19 at 11:16