Stdout to file

GitLab CI/CD
1

Hi

I have a container that I’m using in one my stages that logs out an ID, that I need to capture into a file.
What’s the reccommended way to do this with GitLab. I’m currently trying this:

prepare:run:
  stage: build
  image: 
    name: ${REGISTRY_HOST}/${NAME_SPACE}/${GITLAB_SERVICE}:latest
    entrypoint: ["./main", "-results=false", ">> .env"]
  variables:
    USER: ${API_USER}
    PASS: ${API_KEY}
  script: 
    - echo "Doing stuff"
  artifacts:
    reports:
      dotenv: .env
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  tags: 
    - oci

The following works fine in docker docker run myimage ./main -results=false >> .env. I’m just not sure how to do it in GitLab :slight_smile:

2

This looks about right, but your artifact is not a report. I think you just want:

   artifacts:
     paths:
       - .env
3

Thanks for this, it still resulted in

RUN_ID=919
Uploading artifacts for successful job 00:00
Uploading artifacts...
WARNING: .env: no matching files                   
ERROR: No files to upload
4

Right, so no matching file is a slightly different error. It sounds like maybe the path to .env is wrong. Personally, I would be inclined to put the call to ./main in your script, but at this stage you might want to replace that with something like:

script:
  - pwd
  - ls -lha
  - cat .env

and see what you get.

5

Not a single thing is outputted when I use script, oddly. I also can’t run ./main -results=false from the script either, because I get /bin/sh: eval: line 128: ./main: not found. ls lists the contents of the repo this .gitlab-ci file is in. Rather than the container being used in this stage.

This container I’m using in this stage is not related to the source of this repo. It just does some API things and setups up new test runs etc, it’s just a throw-away container that accepts some variables to construct the right API calls… So the only way I managed to run it was using the image:entrypoint. But it seems I can’t access or i don’t know where the resultant >> .env ends up, but it isn’t in /builds/group/project-name, which does make sense

6

Ah right, because you override entrypoint you are not starting in the normal directory that the runner would choose to clone your code. You can set the variable GIT_STRATEGY: none if you don’t want the code to be cloned at all.

So, presumably the .env file will go on the WORKDIR of your image?

7

OK I figured this out with your help - thanks

prepare:run:
  stage: build
  environment: qa
  image: ${REGISTRY_HOST}/${NAME_SPACE}/${GITLAB_SERVICE}:latest
  variables:
    GIT_STRATEGY: none
    USER: ${API_USER}
    PASS: ${API_KEY}
  script:
    - /main -results=false >> $CI_PROJECT_DIR/.env
  artifacts:
    reports:
      dotenv: .env
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  tags: 
    - oci

So essentially the stage default dir is the builds/group/project. So I needed to make sure I ran main from the root and create the .env into the $CI_PROJECT_DIR. Now the dotenv report seems to make these variables available at to the following stage, whereas the artifacts:path does not. So that is what I wanted and all seems ok. Though, feel free to correct me if something seems wrong :slightly_smiling_face:

8

This looks good! Just a couple of quick things.

You only need to define an environment if you are deploying something or preparing for a deployment. If you are just generating a file, personally I wouldn’t bother.

Reports are for tests, lints, etc where you want to display how many tests pass, paths are for files that you want to pass to future stages. I think what you want here is:

prepare:run:
  stage: build
  image: ${REGISTRY_HOST}/${NAME_SPACE}/${GITLAB_SERVICE}:latest
  variables:
    GIT_STRATEGY: none
    USER: ${API_USER}
    PASS: ${API_KEY}
  script:
    - /main -results=false >> $CI_PROJECT_DIR/.env
  artifacts:
    paths:
      - .env
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  tags: 
    - oci 

next_job:
  stage: whatever
  dependencies:
      - build
    ...

and the dependencies key will pass the artifacts between stages.

The full reference for CI files is long, but it’s worth having it open while you’re working on these things, because there are some subtleties that are well documented (e.g. around environments) and several keys have alternatives.

2 Likes