Building different images for each environment with Gitlab-CI AutoDevOps

Question

Dockerfiles accept ENV variables via --build-args. These vars are mandatory for NextJS, used for static pages (to call remote APIs) and are "Hard coded" within the built image.

Gitlab-CI AutoDevOps has an ENV var to pass these args (AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS). But this is only consumeable if you are using one environment/image. When multiple environments (staging and production) needed, the URLs differ (https://staging.exmpl.com and https://www.exmpl.com).

How do I have to modify the Gitlab AutoDevOps to have two different images built?

In the CI/CD Settings my AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS are set:

--build-arg=API_URL=https://staging.exmpl.at/backend --build-arg=NEXT_PUBLIC_API_URL=https://staging.exmpl.at/backend
# as well $NEXT_PUBLIC_API_URL is set there

Currently this is my complete gitlab-ci.yml:

include:
  - template: Auto-DevOps.gitlab-ci.yml

# added vars for build
build:
  stage: build
  variables:
    API_URL: $NEXT_PUBLIC_API_URL
    NEXT_PUBLIC_API_URL: $NEXT_PUBLIC_API_URL

How can I build two images, without "leaving" AutoDevOps? I assume I have to customize the build stage.

Another idea is to create a second Git repository called production with production URL set for $NEXT_PUBLIC_API_URL:

Staging get build and runs tests.
if successful it gets published
Staging repo content will be copied to the production repo
Production repo gets build (with production URL) and tested and then published too

Then I have two images.

Has someone please a better idea?

Thank you in advance

sytech · Accepted Answer · 2022-02-09T19:56:36.313

Maybe a couple way you can do this. It's pretty easy if you only care about the build job.

One way would be to make a second job which extends: from build

build:
  variables:
    MY_ENV: staging

build production:
  extends: build
  variables:
    MY_ENV: production

Another way might be to add a parallel:matrix: key to the build job

build:
  parallel:
    matrix:
      - MY_ENV: staging
      - MY_ENV: production

Keep in mind, however, if any jobs downstream of build depends on its artifacts, you'll need to manage those as well.

For example:

build:
  variables:
    MY_ENV: staging

build production:
  extends: build
  variables:
    MY_ENV: production

# some other job inherited from a template that depends on `build`
# we also want two of these jobs for each environment
downstream:
  variables:
    MY_ENV: staging

# extend it for production
downstream production:
  extends: downstream
  dependencies:  # make sure we get artifacts from correct upstream build job
    - build production
  variables:
    MY_ENV: production

Thank you @sytech. your first example worked, I only had to add additional `build_artifact`, as well the `script:` because without them, the second build was overwriting the first one as well the first `build_artifact`. So I copied the `script:` part from DevOps original build file and added a suffix to the build name, to differentiate between these two builds — Jan, Feb 09 '22 at 19:46
@Jan glag that worked. Another way to deal with downstream build artifacts is to extend the downstream job and add an explicit `dependencies:` key pointing to the correct upstream job(s). Then the downstream job(s) will only receive artifacts from the respective upstream job(s) you define in `dependencies:`. I'll add this to my answer. However, that may not be easy with `parallel:matrix:`. — sytech, Feb 09 '22 at 19:52

Building different images for each environment with Gitlab-CI AutoDevOps

1 Answers1