How to use /output buildserver in GitLab CI

[David-Hari]

The doco says that it will "write out the variables to whatever build server it is running in".
For GitLab CI with PowerShell, I thought I would be able to access the variables either like $GitVersion_SemVer or as an environment variable like $env:GitVersion_SemVer.

However, neither of those work. When I print all environment variables with dir env: I don't see any of the GitVersion ones.

I am running the CI stage in a docker image, and that image has GitVersion installed using choco. Since I found that variables are not preserved from one stage to another, I had to run GitVersion in the same stage as it is used. e.g.:

script:
  - gitversion /output buildserver
  - mvn install -Drevision=$GitVersion_SemVer

Any idea why that still isn't working?

[AlphaYankee]

The variables are getting written to gitversion.properties. You should be able to use that as a dotenv to push it to the other steps, but GitLab has a limit on the number of variables you can have in there. So what I do is take only the variables I need and write them into a new env file.

Example:

GitVersion:
    stage: Prepare
    image: gitversion:6.0.2-alpine.3.18-8.0
    variables:
        GIT_STRATEGY: fetch
        GIT_DEPTH: 0
    cache: []
    script:
        - |
          /tools/dotnet-gitversion /output buildserver
          grep 'GitVersion_MajorMinorPatch=' gitversion.properties >> version.env
          grep 'GitVersion_FullSemVer='      gitversion.properties >> version.env
          grep 'GitVersion_AssemblySemVer='  gitversion.properties >> version.env
    artifacts:
        reports:
            dotenv: version.env

You could then use those three variables in the next steps.

[David-Hari]

Which kind of defeats the purpose of the /output buildserver option then, which is to be able to immediately use them as variables in the script. But it doesn't matter, I figured out another way to do it.

[AlphaYankee]

Not really, because usually in a CI environment you have one for each thing you do, and then want to use the results of that step in further steps. That's what this accomplishes, and what you usually see done in the examples.

You probably can source the gitversion.properties, but I haven't tested that.