I have a repo that contains a very small, static website and uses review apps for its merge requests. The relevant bits of the CI config look like this:
stages: - build - test - deploy build: stage: build script: - # Generate static site... artifacts: paths: - site environment: name: review/$CI_COMMIT_REF_NAME url: "https://$CI_PROJECT_NAMESPACE.gitlab.io/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public/index.html" action: prepare test: script: # Do something with the artifact # created in the build stage deploy:review: stage: deploy script: - mv site public environment: name: review/$CI_COMMIT_REF_NAME url: "https://$CI_PROJECT_NAMESPACE.gitlab.io/-/$CI_PROJECT_NAME/-/jobs/$CI_JOB_ID/artifacts/public/index.html" auto_stop_in: ...
The value of
environment.url is needed in the
build stage, so that the site generator can set the canonical URL of the site. However, when the site is deployed in
deploy:review the URL will have changed, because
$CI_JOB_ID will be different.
In the past I’ve worked around this by removing the
environment config from the
build stage, and then just rebuilding the site in
deploy:review. In that configuration, the results of
build are used in
test and then thrown away.
This doesn’t feel right, because it breaks the DevOps rule of building only once for CI/CD, but the
deploy:review cannot be predicted (I assume?), and and URL of the job artifacts cannot be changed without hosting the artifacts outside of GitLab SASS.
Is there a neat solution to this that I haven’t figured out, or do other people just build twice?