Leaderboard

Hi, This is not a problem report but more a success story. Well done crew! I heard about caraya when I looked through the talks of VI Week (and I'm still watching videos) and I wanted to give it a go. I've been wanting to try unit testing for a while but the built-in stuff just wasn't doing it for me. We (work) do all our building, releasing and deployment via Azure pipelines so when I heard that caraya can generate JUnit format test results, I jumped straight in and made myself a test pipeline for a new feature we just added to one of our libraries. I downloaded the TDD template, copied the Pre-Build-Action.vi into my project (it needed a bit of fixing) and defined some tests. Once I had the pre-build vi working I looked at the Azure part. I wanted the pipeline to be aware of the test results. All I had to do is to call the Publish Test Results task which takes the results and publishes them to the Azure test repository and bang! Unit testing done. Here are some screenshots And then I added a broken test

I wanted to try JKI Flat UI Control 2.0 with LabVIEW 2020 Community Edition. However, the installation of JKI Design Palette always fails as it seems not supporting LV2020 (at least LabVIEW version 2020 is not listed). Any ideas?

And it works perfectly now, thanks!

I was trying to apply a vipc using the API and it tells me 20.0 isn't a valid LabVIEW version. Digging into I found this: see attached image. Maybe you guys were a little too optimistic about the switch to NXG and figured wed never see 20.0?

Simply removed the case structure and it seemed to work fine.

Curious if there is any plan to ad LV2020 support?

I would mark this as an improvement since in the past it could sometimes take a while for VIPM to refresh everything. I am quite happy with the design palette at the moment, but if I think of anything I will let you know.

Hi Sam. VIPM 2020 works a little bit differently. It hangs around in memory for a little bit in case someone uses it again -- this way, it's much more responsive. Yet, it's changed the observed behavior around exactly when the package list refreshes. This is something we're working on and should be improved in the next release.

That did the trick. Curious - I thought that ran everytime you opened VIPM. Is that true? Does it only automatically do it on some schedule? I swear I had restarted VIPM.

By the may thanks for an awesome toolkit and the quick response!

Hi There! Glad you like the JKI HTTP REST client. For the base URI, I would use: http://192.168.0.100/restapi and then for the path when you call GET or POST, use: /relay/outlets/0/state/ Here's how you could add the X-CSRF header. Note that you can type (or copy-paste) new items into the drop-down selector for the header -- it works like a string control, but with some pre-defined options to make life easier for common headers. The JKI HTTP REST Client passes the username and password into the HTTP VI used by built-in HTTP Open Handle.vi, which I believe doesn't support digest authentication. Under the hood... Digest authentication is something that could be added -- here's the specification and here's a demo server, if you're interested in trying.

Hello LV Gurus, I am creating a simple GUI to control a web (specifically RESTful web server) based DLI Web Power Switch Pro I have three problems: What is the "Base URL" Is it just the IP + port (e.g. http://192.168.0.100:80) or the whole URI including the path to the web server (e.g. http://192.168.0.100/restapi/relay/outlets/0/state/) Where and how do I insert the cross-site forgery ignore in the header (e.g. X-CSRF:x) with your REST API? The Default Header list does not include X-CSRF. Do you support Basic and/or Digest authentication? I get "Unauthorized" error messages using your PUT (or GET) methods returned in the Status String. I then proceeded to create a version of this GUI using cURL (via the System Exec node) to enable switch outlet 1 using "digest" authentication and it works: curl --digest -u admin:1234 -X PUT -H "X-CSRF: x" --data "value=true" "http://192.168.0.100/restapi/relay/outlets/0/state/" FYI: This is DLI guideline for using RESTful HTTP on their power switches Thanks in advance guys. You do wonders for us LabVIEW cogs! Relativity1

We just released a new build with 2020 support https://www.vipm.io/package/jki_design_palette/

There’s a new build of the JKI design palette that supports LabVIEW 2020! https://www.vipm.io/package/jki_design_palette/

Hello All! I'm working on integrating the Caraya test framework into our CI process. As of now, we are using a Jenkins server to manage our builds, but I'm looking to add our Caraya unit tests to that equation. I'm relatively new to the CI world, but have a good amount of experience using Carayas built in test reporting functionality (the text report version). Ideally, upon unit test failure I would like to have the full report sent to the user via email showing them which unit tests did not pass. I know some of this is handled on the Jenkins side, but I'm more so curious about how to properly invoke the unit test VI within my project so that the results and report are available to Jenkins so they can then be emailed. Any and all insights here would be much appreciated. Thank you!

Yes! Thanks for the ping about this Sam. We will update this, very soon.

John, check out "Test Runner Pre-build action.vi" in the 1.0 release. I'm not sure what the current version is on LVTN, but you can find 1.0 on GitHub: https://github.com/JKISoftware/Caraya/tree/release/1.0.0/src The first snippet below is the Pre-Build action itself, the second is the actual guts of where the test gets invoked. Let me know if that doesn't get you started in the right direction or you have more questions.

I'd love to see these three License-related improvements to VIPM: 1) First, a main window column showing the package license, so it becomes very easy to see whether a package is open source, freeware, proprietary/custom, or something else. It'd be nice if the column title could be clicked to sort sort packages by license type: 2) To complement this, a change to the filter box with options to filter by license type, or maybe a second filtering box for this specific purpose. This would further help those searching for packages to focus on finding one they can afford and actually use for new open source projects, which is particularly relevant now that LabVIEW Community Edition is going to bring in lots of new users who definitely aren't going to purchase proprietary add-ons: 3) Finally, it be interesting for the VIPM Community Edition, specifically, to only allow the creation of open source packages, what would create a clear barrier to those who might be thinking of using VIPM Community Edition for proprietary package creation. This could be done by changing the "License Agreement Name" (in VIMP Community Edition only) from a free form text field to a combo box listing only OSI-Approved licenses' SPDX codes, therefore making the intended purpose extremely clear. The default option could be BSD, with other popular OSI-Approved licenses listed below it, and less common ones (if requested) on a submenu: What do you think? 😊 PS: Re-posted with changes from the original in the VIPM 2020 Beta board.