Joerg Hampel

While creating some more screenshots for this post, I actually figured out the problem: It's in the URL of the repo! On the VM where I got the error message, I had not provided the scheme (the protocol, https). It is a bit misleading that the error message (as shown above) will actually display the full URL including the scheme.

Hey VIPM team, we're experimenting with local VIPM repositories but running into problems. We're working in a VM running LV2016 and VIPM 2021.0 (2721) We set up a local repository which should be accessible via the URL https://vipm.hampel-soft.com/ (private, only available internally or via VPN) When trying to update packages, VIPM throws an error In the error logs, there actually is an error associated with the file VIPM wants to download from our custom repository: =========== START of VIPM 2021.0 (build 2721) Error Message =========== An internal VIPM 2021.0 (build 2721) Error has occured on: Sunday May 30, 2021 at 10:02:18 AM = Automated Message Start = Error 42 occurred at (http response "HTTP/1.1 400 Bad Request". URL Requested: https://vipm.hampel-soft.com/index.vipr.zip) 52D9A4562D38CB99A669F85011D9D2EE:1310001 in 9B2F9930B5E536BF44B4C52F860D615E->1C6929D1E714EC131EBDBC872009DE5E->6A6376334CDCAB91B9771788751EE7B6 ->OGPM Class.lvlib:E4D4F8782AE9DBB9105BB3D92B765ACC->OGPM Class.lvlib:8C3E06FF1E6C98D9A8E16799D6B3EEEB->7AF8C3BAECF0AACE1A61F9248BAC879A->VIPM Main Window.vi Possible reason(s): LabVIEW: (Hex 0x2A) Generic error. = Automated Message End = = User Defined Message Start = Error downloading from: - https://vipm.hampel-soft.com/index.vipr = User Defined Message End = = Error Handler Call Chain Start = VIPM Main Window.vi-> 7AF8C3BAECF0AACE1A61F9248BAC879A-> OGPM Class.lvlib:8C3E06FF1E6C98D9A8E16799D6B3EEEB-> OGPM Class.lvlib:E4D4F8782AE9DBB9105BB3D92B765ACC = Error Handler Call Chain End = =========== END of VIPM 2021.0 (build 2721) Error Message =========== Wireshark shows that the HTTP request is denied with a strange error message (see screenshot): Both through the browser and via a simple test VI, I can manually access said file on that LV2016 VM. I then tried adding our repo within another virtual machine running LabVIEW 2018 and VIPM 2021.0 (2694); here our repo works fine! After upgrading the installation in the LV2018 VM from build 2694 to build 2721, our local repo still works for that VM. So it's not related to the VIPM version it seems.

When adding contributors to VI Packages on vipm.io, the UI suggests that one can search for "vipm, github, and gitlab names": I tried that with one of my colleagues who is on GitLab but not on VIPM.io, but the search doesn't bring him up: Should this work?

Hey JKI team, is it possible to programmatically update an existing .vipc (or, alternatively, create a new one) with a given .vip file? Our use is case is the following: After building a .vip automatically, we'd like to install it to the very system it was built on automatically. Seeing as we already have a tool to apply .vipc files through the VIPM API, and as we could use it "as-is" for this, we'd prefer to install the .vip this way. Thanks for the great tool, Jörg

Yes, please, that would be great!

Jim, as always, your elaboration is spot on. Here's a screenshot of what our tools do: So other than the fact that we write all the build numbers in one go (the whole cluster), it's what you described above. Thanks for taking the suggestion into consideration.

With VIPM 2020.3 (build 2540) and VIPM API 2020.0.2.73, it's not possible to supply a major number of 0 via the API, the API returns an error 42: Seeing as we also build projects that are in a pre-v1.0 state, I don't see a reason to not allow the major build number to be 0. I was actually tempted to file a bug report... 😉

For one of our customer projects, upgrading from v1.0.2 to v1.1.0 resulted in an error when trying to build an executable from the project (downgrading to v1.0.2 fixed the build): I understand that we need to tidy our customer's project, having Caraya dependencies in the build is not what we want. The reason I'm posting here is that I'd be interested in understanding why this VI would break the build. Thanks, Joerg

We use G-CLI to execute our CI tools, so we'd write back to G-CLI (and also to the front panel of the tool in case we run it manually). So the point would be to get the progress information back into the VI that's actually using the VIPM API. vipb.mov

Building a VI package can take quite a while. For our Release Automation Tools, it takes about 20 minutes. Even though we build our packages on the build server now, it would be great to be able to feed back the progress of the build process to the CI system. As an example, the NI Application Builder API offers "progress bar" events, which you can register for and then show the progress details as you see fit: The VI Package Builder shows at least a few pieces of progress information in its status bar. Maybe these could be "routed" back to the VIPM API?