It is easy to unintentionally save a VI without changes, or make a change to a VI and then undo it while re-saving. Since it can be difficult to diff VIs locally without additional setup, these changes tend to sneak into pull requests.

The diff bot (and underlying diff tools) could be modified to report back when a VI does not have any changes, and this information could be bubbled up to the pull request explicitly, instead of requiring the reviewer to check the diffs manually.

With the latest submission, OpenVeriStandConnection.vi is broken due to mismatched types.

I just ran into an issue where the Git user was not configured on a build node. This results in a not updated commonbuild-configuration/configuration_20xx.toml.

This was the output of "commonbuild\resources\configPush.bat "Updating NI-XNET-Monitor-Custom-Device for VeriStand 2019 to build number 4.", see also "http://us-aus-hilbuild:8080/blue/organizations/jenkins/NIVeristandAdd-ons%2FNI-XNET-Monitor-Custom-Device/detail/master/11/pipeline/7"
The build number in configuration_2019.toml was still 3.

c:\Jenkins\workspace\NET-Monitor-Custom-Device_master>commonbuild\resources\configPush.bat "Updating NI-XNET-Monitor-Custom-Device for VeriStand 2019 to build number 4." 

*** Please tell me who you are.

Run


  git config --global user.email "[email protected]"

  git config --global user.name "Your Name"

to set your account's default identity.

Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'Administrator@hil-build-node-2019.(none)')

From https://github.com/NIVeristandAdd-ons/commonbuild-configuration

 * branch            master     -> FETCH_HEAD

Already up to date.

Branch 'master' set up to track remote branch 'master' from 'origin'.

Everything up-to-date

git push was successful

Unfortunately I'm not experienced enough in Jenkins magic to fix this myself. Any help appreciated.

Under the Jenkinsfile header you can see a reference to the vs-common-build, it should be vs-build-tools.

Hey everyone,

When I was setting up my own Jenkins server, I installed the dependencies in the repo Readme and I selected the "recommended plugins" option made available to me by the Jenkins installer. Through error messages on failed builds I discovered that I also needed the Pipeline Utility Steps. I also needed to install pip and modify the Path environment variable to include pip's location. I am requesting we add required plugins, pip and any path environment variable changes to the readme dependencies.

I don't know if this counts or not but I also needed to approve two In-process Scripts and this process was triggered through failed builds. I don't know if there is a way to pre-approve the scripts but their signatures are:

• method groovy.json.JsonSlurperClassic parseText java.lang.String
• new groovy.json.JsonSlurperClassic

The reference to LabVIEW Command Line Interface in Readme.md is broken.
Is this meant: http://www.ni.com/en-us/support/downloads/software-products/download.ni-labview-command-line-interface.html?

When trying to get the XML diff for a password protected VI, the operation will hang with a dialog open. This causes the diff pipeline to time out.

#98 enabled the path to dependent libraries to perform target substitution in the libraries configuration in build.toml. Update the documentation in TomlHelp.md to describe how substitution works.

We have template files for our test cases. Diffbot makes separate VI instances for these which can be confusing. See example below for new file testExample.vit.

The readme file outlines the need for the node label 'veristand' and additional labels for each version of LabVIEW installed. The example it gives is "veristand, 2016, 2017". I am using Jenkins 2.176.1 and the commas were preventing Jenkins from recognizing the labels. I needed to remove the commas and separate the labels with spaces.

For some reason text in VIs in the images produced by the diff bot is rendering larger than it should be. For example, the text in the invoke node in this image is much larger than it should be, causing it to clip into adjacent items. This is also affecting comments, so it is not an issue with the invoke node in particular.

I can't say for certain, but I don't recall this happening prior to the build machine being shut off. I had to have someone manually start it today, so I am wondering if it had its screen resolution or DPI changed somehow. @buckd can you look into this?

merge_release_branch.py prints git information as it runs (as a side effect of invoking git directly), but does not display any information as to which repository is being operated on.

It would be helpful if it printed the active repository before updating it.

I would like to have an extra stage that can run arbitrary tests.

This would be for either unit testing via UTF, or to run a TestStand step. It should also allow for adding different testing methodologies in the future.

I would imagine that the build.toml would point to the tests to be run, and it would look similar to the build.steps.

Hey everyone,

Simon (and I think also Donovan) mentioned something to me while I was trying to resolve several different build errors. He told me that the build tools need to be in the same organization as the repo you are trying to build. When you create a project in Jenkins there is nothing preventing you from configuring the project owner to be different than the owner of its Shared Pipeline Library. Issue #33 is an enhancement issue requesting more flexibility here and it is still open. I am suggesting a note in the documentation while this constraint exists.

There seems to be a race condition in the Jenkins parallel build gathering that causes some builds to build for the wrong version of LabVIEW. We can't reliably reproduce it, but there is a common pattern I've seen.

When the pipeline stages are created, if all of the stages for a given version are created before another version starts creating the pipeline, everything looks good. However, if the stage creation happens in an inter-leaved manner, things will build for the last version created.

Correct builds happen when stages are constructed for a single version at a time:

Incorrect builds happen when stage construction is interleaved. This will build for LV 2018 twice instead of 2017 and 2018:

New build.toml entries were created as part of #124 and need to be documented in the toml help.

Because we have multiple parallel builds for different versions of LabVIEW in a single pipeline, the archiving is performed for each version from the individual node where the build is executing.

This means that if a build for one lvVersion is successful, that build is copied to the archive location. However, if one of the builds also fails, we are left with an export that contains some, but not all, of the expected versions. This causes problems when we want to find the latest build (to create feeds). There is no way to tell if a given export is actually good.

Because there is now a Validation stage that checks to make sure all versions were exported, if they are not all there, we should remove that build from the archive location. This allows us to only keep good builds. It makes creating feeds easier and also frees up disk space.

I was modifying the Scan Engine EtherCAT custom device in a way that required coordinated changes to both the custom device and modules library repositories. The logic in https://github.com/ni/niveristand-custom-device-build-tools/blob/master/vars/buildDependencies.groovy should handle this, however the target branch (dev/add_9266) was not correctly found on the modules library and the build fell back to using the master branch.

It appears that the presence of a '/' in a branch name causes that branch name in dependencies not to be found, probably because it is looking for a subdirectory.

Multi-repo builds attempt to use the same branch name on all sources, falling back to master if no corresponding branch exists in a dependency. This works well for general branch builds, e.g. release branches.

In pull-request builds, we are using the pull-request number (e.g. PR-44) instead of the branch name (e.g. dev/build-cleanup) to do this lookup. This results in build failures where coordinated pull-requests are made in multiple repositories that require the other changes to build successfully.

See ni/niveristand-scan-engine-ethercat-custom-device#44 for an example.

When building the latest PR in Instrument Addon, I'm getting failures from the LV CLI call. Looking at the build log versus the last successful build, there are double quotes around the ProjectPath parameter:

-ProjectPath ""C:\agent_work\37\s\niveristand-instrument-addon-custom-device\Source\Addon\Instrument Addon.lvproj""

I'm guessing this is an issue introduced in #165, specifically the double quotes around the string that already contains quotes.

Full log comparing the two strings below:

PS C:\agent\_work\37\s> LabVIEWCLI -PortNumber 3363 -LabVIEWPath "C:\Program Files\National Instruments\LabVIEW 2021\LabVIEW.exe" -AdditionalOperationDirectory "C:\agent\_work\37\s\niveristand-custom-device-build-tools\lv\operations"     -OperationName "ExecuteBuildSpec"     -ProjectPath ""C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\Source\Addon\Instrument Addon.lvproj""     -TargetName "My Computer"      -BuildSpecName "Host API"      -LogFilePath "C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\lvBuildSpecs.log"
LabVIEWCLI started logging in file:  C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\lvBuildSpecs.log
Using LabVIEW: "C:\Program Files\National Instruments\LabVIEW 2021\LabVIEW.exe"
LabVIEW launched successfully.
Connection established with LabVIEW at port number 3363.

Operation output:
Error Code : -350051
Error Message : LabVIEW CLI: (Hex 0xFFFAA89D) The CLI for LabVIEW failed to run the operation because the command contains illegal arguments.
An error occurred while running the ExecuteBuildSpec operation.

ExecuteBuildSpec operation failed.

PS C:\agent\_work\37\s> LabVIEWCLI -PortNumber 3363 -LabVIEWPath "C:\Program Files\National Instruments\LabVIEW 2021\LabVIEW.exe" -AdditionalOperationDirectory "C:\agent\_work\37\s\niveristand-custom-device-build-tools\lv\operations"     -OperationName "ExecuteBuildSpec"     -ProjectPath "C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\Source\Addon\Instrument Addon.lvproj"     -TargetName "My Computer"      -BuildSpecName "Host API"      -LogFilePath "C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\lvBuildSpecs.log"
LabVIEWCLI started logging in file:  C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\lvBuildSpecs.log
Using LabVIEW: "C:\Program Files\National Instruments\LabVIEW 2021\LabVIEW.exe"
Connection established with LabVIEW at port number 3363.

Operation output:
Generated files are:
C:\agent\_work\37\s\niveristand-instrument-addon-custom-device\Source\Built\IA\Custom Devices\Instrument Addon\Windows\Host Automation API\Instrument Host Automation API.lvlibp

ExecuteBuildSpec operation succeeded.

The Archive stage only archives the files located in the build_output_dir specified in build.toml. We should enable archiving an arbitrary number of directories because sometimes that makes more sense than forcing things to build in a single location.

There is a mechanism for replacing tags in the build.toml file like {veristand_version} and {labview_version}. However, these tags are currently only evaluated during the Nipkg stage. It would be useful to evaluate these tags before the pipeline is constructed so they can be used anywhere in build.toml.

This would help with Issue #67 .

The manifest.json file currently gets generated in Built/installer. When the NIPKG stage runs, it copies the payload_dir (which will typically be Built) to a staging directory and then builds the package out of that stage. Before the manifest, this worked fine, but now the manifest file is also included in this staging, so the resulting .nipkg includes and installs the installer/mainfest.json file.

We should not install the manifest with the custom device.

The Scan Engine custom device builds some components using 32-bit and some using 64-bit LabVIEW 2021. The build tools currently build all packages for any bitness. This means that the package output is sometimes an empty payload. For instance, if we build the scripting API in LabVIEW 64-bit, but not 32-bit, we still try to build the package for 32-bit. The package will build, but will be empty. If 32-bit is the second version to complete, the empty packages will overwrite the correct packages.

This work should be very similar to #119 and #122

What are the necessary Jenkins plugins to set up the server?

It'd be great if someone knowledgeable could go through the list and list which ones are necessary.

I created this groovy script to run in the Jenkins console in the web interface to generate a script that mirrors all plugins

def plugins = jenkins.model.Jenkins.instance.getPluginManager().getPlugins()
print "for (plugin in ["
plugins.each {println ""${it.getShortName()}","}
println "]) {"
println " e = Hudson.instance.updateCenter.getPlugin(plugin).deploy().get().getError()"
println " if (e != null)"
println " println e.message"
println "}"

It's based on this https://www.noqcks.io/notes/2017/07/10/jenkins-installed-plugins-list/ and modified to create a similar script to https://gist.github.com/whittlec/6112643

Currently the zip package stage will zip up a folder and deposit it in the Built/Installer folder. For dynamic information, such as binary output, this is useful as we can have unique versions based on VeriStand year versions. For static information, such as source, this is wasteful as we have duplicate copies of the same information. It would be nice if there was a way to specify the destination folder of the zip package.

PR #104 added two new groovy files that require a virtual environment before calling the python code needed. This virtualenv code is duplicated in multiple locations. See if there can be a single groovy call to bat to set up the virtualenv and pass the python command to that virtual environment.

This won't mean we don't need to set up the virtual environment multiple times, just that the code is only located in a single function.

Diffing fails for VIs which are in LabVIEW classes, with the following error reported by the diff bot:

Operation output: 
Error Code : 1498
Error Message : Get LV Class Default Value.vi<APPEND>

<b>Complete call chain:</b>

     Get LV Class Default Value.vi

     VIDiffUtilities.lvlib:LoadContainer.vi

     VIDiffScreenshots.lvlib:CreateVIPictures.vi

     VIDiffScreenshots.lvlib:DiffVIs.vi

     DiffVI.lvclass:RenderDiff.vi

     DiffVI.lvclass:RunOperation.vi:5910001

     CoreOperation.lvclass:CallRunOperation.vi:4230002

     ExecuteRunOperation.vi:5250001

     ExecuteOperation.vi:6900002

     ExecuteOperation.vi.ProxyCaller



<b>LabVIEW attempted to load the class at this path:</b>

C:\jenkins\workspace\-device-testing-tools_PR-36-6VZK764BEV4AGDLMHFZV3VF6ZNJICOCEEL2ZHN2QFYSYUHZF6NXQ\VeriStandTestCase\VeriStandTestCase.lvclass
An error occurred while running the DiffVI operation.

DiffVI operation failed.

The build tools can also build zip packages, but this is not documented in the TOML reference.

Currently, when you use Jenkins to pull in the build tools as a library, it pulls from the location specified as the repo in the Jenkins configuration. However, in the cloneBuildTools.groovy step it pulls the build tools from the organization that the repo going through the buildpipeline is from.

As an example, if I am trying to use Jenkins for CI on my repo called ExampleRepo located in ExampleOrg but I want to use the build tools from another organization called SeperateOrg then Jenkins will correctly pull the build tools from SeperateOrg but niveristand-custom-device-build-tools will pull the tools from ExampleOrg/niveristand-custom-device-build-tools if it exists (otherwise it throws and error)

As far as I can tell, this is because the code in niveristand-custom-device-build-tools/vars/cloneBuildTools.groovy get the organization containing the repo passing through the pipeline and uses that to clone the build tools.

It would be great if the build tools cloned from the same org specified in the Jenkins configuration.

The Jenkins DSL function deleteDir() tries 3 times to remove a specified directory, with a 0.1 s delay between tries. Sometimes, this is not enough and our build fails because something in memory still has not released all the files, so deletion fails.

We should be able to add a longer timeout/more attempts to reduce the likelihood of this happening.

Microsoft Teams notifications were added in #95 but the TOML documentation was not updated. Add information about how to configure notifications in TomlHelp.md and note what environment variables must be set on the build machine.

reference failed build:
https://nijenkins.amer.corp.natinst.com/blue/organizations/jenkins/NI%2Fniveristand-data-sharing-framework-custom-device/detail/PR-2/16/pipeline/50/

even on passing builds, the time required to complete the 'check out from version control' is more than 90 % of the timeout.

Currently, we can only specify the version of LV to use as the year-only version. This breaks down if we have a service pack version of VeriStand (or some other version) that installs assembly versions other than $lvVersion.0.0.0.

When VeriStand begins releasing more frequently, we're going to need to handle these different assembly versions.

Hey everyone,

When I was first playing with these tools I was trying to create a Multibranch Pipeline because that is what I was familiar with. When Jenkins tried "Cloning build tools to workspace" it was always inserting "null" for the organization within the repo url. Donovan informed me that he experimented with making MP work with the tools but in the end decided to stick with the GitHub Branch Source Plugin. I am requesting we document which Jenkins items are compatible with these tools.

Greetings everyone;

The current documentation for the repository is contained within a Readme file that describes a few comments on the usage of the repository. There is also a Wiki with information on the TOML, but it is not obvious to find.

To my knowledge, we cannot link a PR to a change in the Wiki (or vice-versa). I would propose that we change the documentation to having the main Readme discuss the repo structure and contents, and link to other articles or readmes within the repo. This would be similar to how a few repos in the DCAF org are organized. Example from the DevGuide.

Regardless of whether the main Readme is changed, I would like to bring in an updated, shortened, Markdown version of Pollock's Getting Started Guide for Jenkins.

Currently the diff bot looks for *.vi files, but not *.vit files. While we only have a few templates in our source code it would be convenient if the diff bot handled those as well.

Because the archive_location is specified in build.toml, if forks of a repo are created and use the automated build system, when those builds execute they can overwrite previously archived build versions.

In the example https://github.com/ni/niveristand-engine-simulation-toolkit-custom-device/blob/master/build.toml , line 41, the {veristand_version} tag is used to get the VeriStand version based on what was defined in the Jenkinsfile.

I am trying to use this approach on our build machine but every time I run my Jenkins pipeline, the tags defined in the build.toml are not replaced at runtime.
For example, the path of the file is 'documents\National Instruments\NI VeriStand {veristand_version}\Custom Devices' instead of 'documents\National Instruments\NI VeriStand 2017\Custom Devices'.
Is there an environment variable that I need to add, or something else I need to declare in order to make this work? Am I misusing the framework?

I'm also having the same issue with the tags {display_version}, {nipkg_version} in my NIPKG control file. Here is an example of the file I’m trying to replicate https://github.com/ni/niveristand-engine-simulation-toolkit-custom-device/blob/master/control

Whenever the script.getComponentParts()['repo'] or the script.getComponentParts()['organization'] from the src/ni/vsbuild/stages/Archive.groovy stage are being called they give null. Is this a bug or have I configured something wrong?

The current mechanism for substituting the LabVIEW version used to build a given repo only substitutes the year version. This was fine when we only built for 32-bit LabVIEW, but with the addition of 64-bit support, we need to be able to build nipkg files that install to the correct location based on architecture. This is required in order to build packages for the custom device build tools and LabVIEW scripting APIs and examples.

The Manifest, nipkg labels, and mark package built step of the Packaging stage fails when building release branches with no packages defined. This is causing the release/23.5 build of Scan Engine's dependencies to fail:
https://ni.visualstudio.com/DevCentral/_build/results?view=logs&buildId=4947981&jobId=3bd4616a-ba05-5ecb-8884-5259017d0dbc&j=3bd4616a-ba05-5ecb-8884-5259017d0dbc