Wow, thats actually very different from what I expected.

So, now it depends, what is your application right now. If your application is a WEB Based, or textual terminal application it will be very different.

If it is a WEB, so, I think you can try some TWAIN libraries, as this device should support twain.

Or, it looks like it can just export image files somewhere, where you can just catch them.

Can you give some more details about your application and expected workflow?

The best solution right now would be to use something more modern than Jenkins, something base on Docker.

You can do it with any other on-prem tools like GitLab-CI, or Jenkins-X.

Some time ago I did some example repository for GitLab-CI, with Kubernetes deployment. I did not check it for a while, so, it may not work like it in the beginning, but I think it still can be useful as an example.

Another solution, I've implemented in one of the previous projects. I used pre-commit hooks, where I have some simple parser and scanned code for some temporary globals, such as ^tmp*, ^debug, ^log and so on (we actually had some naming convention for such global names), and it also checked for forbidden commands break, zwrite, zbreak.

By now I think would be good to add some checks to an editor as well, so, I think to add it to my VSCode-ObjectScript. So, VSCode will highlight recognized as debugging lines, as an error or warning.

My VSCode-ObjectScript extension supports the same versions as Atelier, so Caché/Ensemble versions from 2016.1.

You can not just edit mac routines, and classes, compile and do many other features. And it is also supporting Intellisense. CSP support, just very simple, only syntax highlighting as HTML, as it already stored as files, you can just use the same folder in Caché and in VSCode, and everything should be OK. You can find details about the latest features here, and use the arrow buttons to navigate to the previous release notes.

And now, we are also offering enterprise support, so, you will get faster issues solving, and may get some priority in realization new features.

When you have || in Id, it usually means, that you have additional Index by two or more fields, and marked as IdKey. Something like this.

Property RollNo As %String;

Property Marks As %String;

Index RollNoMarks On (RollNo, Marks) [ IdKey, Unique ];

Here we have some two properties, to store both values separately, but we used both of their values as IdKey.

Now it is possible to check of existing an object by ##class(User.School).%ExistsId(RollNo_"||"_Marks), or open id by  ##class(User.School).%OpenId(RollNo_"||"_Marks)

But in additional to this system methods, we now have some new ones which construct with index name and "Exists", "Open" and so on. But call will be a bit different. You should pass all values separately in this way.

##class(User.School).RollNoMarksExists(RollNo, Marks)

##class(User.School).RollNoMarksOpen(RollNo, Marks, , .sc)

You can try any of these ways, and you should remember about Status variable, which may help you to understand what's happening.

do $system.OBJ.DisplayError(sc)

will decode status

Sure, we can discuss here, or in github

Yes, some IntelliSense options need connection to the server, yet for now. Like, it's easier yet to get a list of methods directly from server, instead of parsing all files locally. But some things, such as commands and system functions should work without a connection. As well as go to definition if file exists locally. It is possible to add loading METADATA info prepared for Atelier, to use it as a cache for system classes, but it anyway will need a connection to a server at least once.

Rubens, thanks for the donation. 

You can just disable a connection with "objectscript.conn.action": false, and activity with a server will be disabled,  autosave as well.

Actually I had this option previously but removed it recently. If you would like to have this option, just fill the issue, I will add it.

It's cool, that more and more extensions will appear, to add more features. 

btw, are you going to GlobalSummit, so we would have some discuss there?

It is not actually a bug, it mostly expected behavior. I'm not sure about Windows (just, too lazy to check it there), but in *nix systems, folders and files just act almost exactly the same way, there only one difference in one flag, D for directories. And if you would like to check the difference just look at the method DirectoryExists also in the %Library.File class