LabVIEW and Gitlab Package Registry

In this post I want to discuss about a feature not very known by many users of Gitlab. Since version 13.5 Gitlab has available the generic package registry, which is a way to upload “generic packages” to Gitlab.

Build Storage Dilemma

Before getting into the package registry subject, there is a very important thing to pay attention here. The storage of builds inside Git repositories.

This is definitely not the ideal approach, and this statement is constantly repeated everywhere and every time. Most of you will agree, but some still ignore and insist in uploading results of a build with the source code.

Well, the name already says: Source Code Control Management not Build or Artifacts Management, right? So, unless you have a very specific reason (it is possible, why not?), avoid using the git repository to store your artifacts.

In LabVIEW this applies to .exe, .rtexe, .vip and .lvlibp, and some more, I can’t remember them all. By the way, in Gitlab the .gitignore file template already have those included (check it out).

If you don’t know what to do with your builds, check the solution below.

Package Registry

With the release of the Gitlab Package Registry, some of the most common package managers could rely on the Gitlab for registry of their private packages.

This is a huge advantage, because you won’t have to set another private server just to host a registry such as PyPI, npm or NuGet. And the list of supported package managers keep growing in the coming versions of Gitlab.

More information about that on: https://docs.gitlab.com/ee/user/packages/package_registry/

With this feature you can you can see ALL your packages in a group level.

What about LabVIEW Packages

Seeking to solve this problem from LabVIEW, not specifically, but from other languages too, since the 13.5, the Generic Packages are available. They are actually there to fill the gap of the package managers that are missing.

Of course, it is not the same thing as Standardized Registry, but it is possible to use the package registry to store your artifacts with versions after the build job in your CI Process.

So, how can I do it?

Easy Way

The easiest way is to follow the instructions provided by Gitlab (extracted from Gitlab), using Curl and the Job Token.

image: curlimages/curl:latest

stages:
  - upload
  - download

upload:
  stage: upload
  script:
    - 'curl --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file path/to/file.txt "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/my_package/0.0.1/file.txt"'

download:
  stage: download
  script:
    - 'wget --header="JOB-TOKEN: $CI_JOB_TOKEN" ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/my_package/0.0.1/file.txt'

You can read at: https://docs.gitlab.com/ee/user/packages/generic_packages/index.html#publish-a-generic-package-by-using-cicd

As you can see, the Job Token can be used for uploading, so no need for creating Private Tokens as Variables to be used in this job.

As example, I used in one of my public projects: https://gitlab.com/felipe_public/gitlab-tools-labview/build-cli-operation

In the pipeline, I set the both jobs (Release and Upload) to run in parallel as I already knew the resulting link from the package registry. I used that link to insert as a “Release Asset”.

Other way

You can always complicate things, of course, in this case, by using LabVIEW to deploy manually your package to the Generic Package Registry, below is a small snippet for this operation in LabVIEW.

Thoughts?

Did this feature help you? Let me know what you think in the comments.