Development mode works on contributors fork but not on NI's infrastructure #408
Replies: 9 comments
|
Root cause has been identified: This is the command to set development mode on a 32-bit execution of LabVIEW: This same command will work on my local setup, but i observed that the VM used to build the VI Package (NI Infrastructure) will take a long time to load especially if you just loaded G-CLI. 
This is causing an edge case that we have not had the opportunity to exercise until now. |
|
Note: i switched to the 64-bit version of the command It was discovered that even though the G-CLI script failed, setting development mode is running unattended after the failure. This creates a problem when a user attempts a retry, since it took almost 17 minutes to finish executing the previous chain of calls to G-CLI that were embedded on the failing script. This calls for a more robust error handling around this edge case. |
|
A workaround for this is to kill LabVIEW directly on the runner, and try the command again. The problem statement is that the "first run" needs refinement. 
I suggest not spending more time on this workaround and wait until the minimum supported LabVIEW version is set to 2023, i suspect this would cause a significant improvement. |
|
After i did the above directly on the runner, I retried a a failing job and it now works. No changes in code were necessary to solve this problem Complete log of the successful retry attempt has been uploaded here |
|
this log contains the failing job from PR #406 before fixing the runner manually with the process described on the above comments. |
|
I made a retry on a failing run now that it was successful on getting development mode enabled. It failed the first time on the |
|
After retrying the LUnit unit tests for the 32-bit execution of LabVIEW, it passed. |
|
Building the PPL for both 32 and 64 bit versions of LabVIEW 2021, but failed on the VI Package job I will retry the job to see if it works. |
|
We have taken actions with #456 that eliminates the need for Development Mode. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Runner environment differs: failing run executes on
US-AUS-OSCI1(actions/checkout@v4, reponi/labview-icon-editor, Git 2.48.1, global config copied fromsystemprofile), while the passing run usesUSAUSLT-Z7DLW6G(actions/checkout@v3, reposvelderrainruiz/labview-icon-editor, Git 2.51.0, config copied from the user profile).Git checkout targets differ: failing job syncs
origin/developat commit126ff79b…; passing job syncs feature branchcodex/investigate-compute-version-action-failureatdb2a44e….Detected LabVIEW installations vary: failing run only lists 2021 SP1 (32/64), 2023 Q3 Patch 6 (64-bit) and 2025 Q3 Patch 2 (64-bit); the passing runner also has 2020 SP1, 2023 Q3 Patch 7 (32-bit), 2025 Q1 Patch 2 (32-bit), and a 2026 Q1 build.
Key behavioral gap: both runs invoke
AddTokenToLabVIEW.ps1for LV 2021 (32-bit), but the failing log shows G‑CLI stuck waiting for LabVIEW to connect and timing out after ~85 s (No connection established with application, exit 1). The passing run establishes comms within ~12 s, exits G‑CLI cleanly, and proceeds toPrepare_LabVIEW_source, 64-bit token creation, closing LabVIEW, etc. None of those later stages appear in the failing run.Post-failure cleanup differs: failing run aborts immediately after the first AddToken step and terminates the orphan LabVIEW PID 8664; passing run completes all subsequent scripts, writes JSON output, and only then performs cleanup (including terminating various NI processes).
All reactions