Issues with Gitlab Pages CI to deploy /public files

Hello, I have created a hugo site. The way I have things configured now, My source is managed by one Git repo, while the /public (which will be served) is another Git repo I am attempting to use for Gitlab pages, but the CI keeps failing and I can’t work out why.


image: alpine:latest

  stage: deploy
  - echo 'Nothing to do for plain HTML...'
    - public
  - master

I based the file off this example for serving plain HTML on Gitlab Pages

Here is the output on the pages pipeline:

`  on docker-auto-scale 72989761` `  feature flags: FF_GITLAB_REGISTRY_HELPER_IMAGE:true ` `Resolving secrets  
  ` `Preparing the "docker+machine" executor  
 ` `Using Docker executor with image alpine:latest ...` `Pulling docker image alpine:latest ...` `Using docker image sha256:49f356fa4513676c5e22e3a8404aad6c7262cc7aaed15341458265320786c58c for alpine:latest with digest alpine@sha256:ec14c7992a97fc11425907e908340c6c3d6ff602f5f13d899e6b7027c9b4133a ... ` `Preparing environment  
 ` `Running on runner-72989761-project-25837132-concurrent-0 via runner-72989761-srm-1618257485-44fd1980... ` `Getting source from Git repository  
 ` `$ eval "$CI_PRE_CLONE_SCRIPT"` `Fetching changes with git depth set to 50...` `Initialized empty Git repository in /builds/ryder-d/` `Created fresh repository.` `Checking out 41d86fdc as master...` `Skipping Git submodules setup ` `Executing "step_script" stage of the job script  
 ` `Using docker image sha256:49f356fa4513676c5e22e3a8404aad6c7262cc7aaed15341458265320786c58c for alpine:latest with digest alpine@sha256:ec14c7992a97fc11425907e908340c6c3d6ff602f5f13d899e6b7027c9b4133a ...` `$ echo 'Nothing to do for plain HTML...'` `Nothing to do for plain HTML... ` `Uploading artifacts for successful job  
 ` `Uploading artifacts...` `WARNING: public: no matching files                 ` `ERROR: No files to upload                           ` `Cleaning up file based variables  
 ` `Job succeeded`

The pages:deploy fails with missing pages artifacts

You don’t have a public directory in your repository—everything is in the root.

What is the best solution to manage the source code as such? Changing the path to / or ./ it still fails, now with the error no entries extracted Using . fails with the missing artifacts error.

Did you read this?

Yes and it does not outline what I am trying to do. I am trying to serve ONLY the public folder with the source being a seperate repo, as this seems to be the only benefit of using HUGO or any static site generator. What is the point of dumping “static files” to a public folder if one still needs to run HUGO on a “server”? The whole selling point of HUGO is that it is static and can be served with only a HTTP server Also, when I actually look at the source in public, it’s html with completely broken styles and links, so I am really strugging to see the advantage.

I am sorry that you are struggling.

If you only wish to use GitLab to serve the public directory created by Hugo, then follow the directions you referenced in your initial post. Make sure to look at the picture that they provided; it shows a public directory in the root of the repository. You need to make your repository look like their picture. The directions they provide are generic; there is nothing specific to Hugo. If you have difficulty making this work, you should contact the team at GitLab for assistance.

You might start with a simple “Hello World” example to figure things out.

├── public
│   └── index.html
├── .gitlab-ci.yml

Where index.html is:

<!DOCTYPE html>
<html lang="en">
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, minimum-scale=1.0, initial-scale=1.0">
  <title>Hello World</title>
Hello World!

Once you have a simple example working, then try it with the files generated by Hugo.

If you continue to experience HTML with completely broken styles and links, please create a new topic on this forum, sharing a link to the source code for your site including configuration, data, content, templates, etc.

Regarding the benefits of static site generators… for you, perhaps none. You might find something like Wix, WordPress, or Google Sites more to your liking. For others, the benefits include reduced cost, better security, fewer moving parts, improved reliability, content under source control, continuous integration, etc.

Again, I am sorry that you are struggling.

1 Like

This is my Ci/CD Pipeline for Hugo in Gitlab CI/CD. I am Building and Deploying with docker and SSH

I have following directory stucture:

  • pages (This is where my hugo project is in)
  • Dockerfile
  • gitlab-ci.yml

My Gitlab-Ci.yml


  - test
  - build
  - upload-docker
  - deploy-server


  stage: test
    - cd page
    - hugo
    - test

  stage: build
    - cd page
    - hugo
      - page/public
    - master

   image: docker:latest
   stage: upload-docker
     - docker:dind
     - docker build --pull -t "$CI_REGISTRY_IMAGE" -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
     - docker push "$CI_REGISTRY_IMAGE"
     - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
     - master

  image: alpine
  stage: deploy-server
    - apk add openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh -o StrictHostKeyChecking=no "cd ~/dockerfiles/app-protoncode; docker-compose pull && docker-compose up -d"

My Dockerfile looks like this:

FROM httpd:alpine
COPY ./page/public /usr/local/apache2/htdocs/

Maybe this helps you?

1 Like

Is there a reason you’re running with Docker for just Hugo? I’ve worked with Docker a bit, but I am not seeing the use case here. Regardless, thank you for your input.

It looks like I may need to change my approach to hosting Hugo. My initial thought was to host the codebase in one repo, with the content being a Gitlab Pages repo, but the behaviour of github pages doesn’t seem to support this structure without modification of folder structure. As you’ll see by my previous comment, it always seems to fail trying to use the root instead of /public on the repo.

I also may be having an issue with content rendering, as opening the files locally or attempting to host on Netlify results in completely broken site. On that front I’ll likely create another thread RE @jmooring comments