Glad this is settled!

I think open-source and private IP policy should be balanced. But Microsoft's financial success and approach which let company to become a largest contributor to open-source could be a good argument that balanced open-source contribution maybe connected to company's prosperity.

Regarding user/pass - it should be a user and his/her password that is allowed to access web app /registry in your IRIS server.

You can go to the list of Web Apps: http://localhost:52773/csp/sys/sec/%25CSP.UI.Portal.Applications.WebList... and observe other and setup your own.

It can be passwordless, basic authentication, bearer token, OAuth, delegated - whatever you decide in your system.

If you are on a community edition of IRIS from a vanilla iris docker image then login/pass you use for your admin access, e.g. to access Management Portal http://localhost:32783/csp/sys/%25CSP.Portal.Home.zen

will work for the registry as well.

There are two steps to publish into a registry. 

1. Load a package into a namespace - you can load from a file directory that contains module.xml, or from a github repo, e.g.

load /folder_with_module/

2. switch to a current registry, where you can publish. You can install your own registry, or use  a test registry, which is always avaliable for different tests:

ZPM:USER>repo -n registry -r -url https://test.pm.community.intersystems.com/registry/ -user test -pass PassWord42

3. Publish a pachage with the command:

publish package_name

Hi @Jani Hurskainen ! Have you solved your question with publishing in a registry?

@Jani Hurskainen , do you have your unittest framework published as open-source by a chance?

Nice workaround! 

@Timothy Leavitt, do we want to consider support alternative unittest framework in IPM client? 

No problem found it https://github.com/intersystems/ipm/releases

First I went to OEX and didn't find it there.

Great news, @Timothy Leavitt!
How can I test the 9.0 beta IPM client?

I see your point, maybe the IRIS package will not help here. But thinking loud I could imagine a user-specific setting that will lock a particular SMP language just for the user you are signing in with. Here the package providing such a functionality could help.

Thank you, @Alexander Koblov !

Sounds like an opportunity for a usefull "addon" package for IRIS, no?

Thank you, @Alexander Koblov !

Should the developer of the REST.API service call this method everytime, or there is a way to understand whether the Audit is on for the particular REST.API service? 

Thank you @Timothy Leavitt !

Thank you, @Timothy Leavitt 

I'll take a look, thank you

I recorded a video to demo that.

Hi @John Murray !

Yes, it just works, thanks to @Timothy Leavitt and his team.

The only thing you need is to make sure that your dev module is described via IPM, and install and setup git-source-control.

Here is an example template for interoperability production that demonstrates the feature. 

And here is the only setup line that is needed after git-source-control is installed via IPM:
 

 zpm "install git-source-control"
    do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

@Brett Saviano , maybe I'm mixing something up, but I'm just trying to provide you feedback, that developers that follow the client-side paradigm (actually the majority of existing developers to my knowledge) should still have any option to edit BPL/DTL and DFI and today the way is via server-side UI tools, and of course, they would expect changes reflected in their client git setup, which git-source-control wonderfully does.