LabVIEWCLI Error 1370 with Gitlab CI

[cordm]

Hello integrators,

I set up a continuous integration job with Gitlab that is supposed to build executable and installer of an application with two calls to LabVIEWCLI. The executable is built successfully but the installer build fails with this error:

Error Code : 1370
Error Message : mxLvErrorHandler.vi:2660001
An error occurred while running the ExecuteBuildSpec operation.
ExecuteBuildSpec operation failed.

Running the builds from a command line or from within LabVIEW works, so it should not be an error in the build spec.

Any ideas what could be causing this? Does anyone use this approach or should I create an artifact from the executable to be picked up by another job? Splitting into multiple stages at least didn't work.

[AryaStark92]

We are facing the build issue with packed library file when triggered from Jenkins

[Jens_S]

Have you checked if the CLI calls are made by the correct user? I don't use Jenkins but with Gitlab and the Gitlab runners we often had problems that they run scripts with a local system account which led to numerous problems regarding access rights.

[joerg.hampel]

---

@cordm wrote:

Any ideas what could be causing this? Does anyone use this approach or should I create an artifact from the executable to be picked up by another job? Splitting into multiple stages at least didn't work.

---

I can't speak to the LabVIEWCLI (as we use the G-CLI), but we also execute multiple build specs within a single job to avoid unneeded artifacts. That should not be a problem. We've been doing that on GitLab/gitlab-runner, Bitbucket/Jenkins and Azure DevOps/agent.

How do you start the gitlab-runner? If you're starting it as a service, I highly recommend running it from a regular PowerShell, which should make debugging much easier.

PS: Cord, If you're coming to WUELUG#16 we could have a chat 🙂

[Taggart]

Curious why you are avoiding artifacts?

[joerg.hampel]

---

@Taggart wrote:

Curious why you are avoiding artifacts?

---

It's not so much about avoiding but rather using them where they make sense for us.

1. We have our own mechanism for providing the pipeline's results, so we don't use artifacts for that (read: we have no need for build results in the artifacts).
2. By combining multiple executions into a single job, we save time - both for not having to start another job and for not having to upload/download artifacts.
3. We do use artifacts for the reports (unit tests, VI Analyzer, documentation, DQMH Validator), which are convenient to browser from the web UI and which are kept (not deleted after a certain amount of time).