ClearCache addition to LabVIEW CLI

[TiTou]

Something a bit surprising happened to me today with my GitLab CI :

I have 2 runners, a Linux one and a Windows one (yes, my code is supposed to compile on both OSes)

After a push on a feature branch, my runners were triggered, my steps are

- mass compile the project folder

- run unit test suite (I use Caraya)

- run module validation (DQMH)

- compile EXE

- Close LabVIEW

All the steps went fine on both runners. This feature branch is not yet ready to be merged in dev

The a bit latter, back on my dev branch, I push a few commits, my runners were triggered with the same steps

On the Linux runner, all went fine and the Windows runner failed during mass compile.

I went on the Windows runners opened the project to take a look at the broken VIs, it turns out that a typedef cluster was causing some broken VIs, what really surprised me is that it had the modifications made on the feature branch.

No, I'm not crazy, I didn't do anything stupid in git.

So I didn't do any modification on the runner,

I closed the project,

Cleared the compile object cache,

And closed LabVIEW,

Then I went on GitLab and manually triggered the runner again on the dev branch : all the steps completed successfully.

So I created a "ClearCache" addon for the LabVIEW CLI and included it before the mass compile in my CI steps.

Has anyone ever seen this?

I'm blaming LabVIEW for this, am I wrong?

[Taggart]

I don't know who is to blame, but I have definitely encountered this and I have written a similar G-CLI step to clear the cache and call it very liberally.

[joerg.hampel]

Our Release Automation Tools programmatically clear all caches at the start of every pipeline, and again clear the appbuilder cache before each build job.

[TiTou]

Thank you both for your feedbacks, so I'm not alone.

---

@joerg.hampel wrote:

Our Release Automation Tools programmatically clear all caches at the start of every pipeline, and again clear the appbuilder cache before each build job.

---

Nice acronym 😅