We greatly appreciate the support for FHIR packages in 2020.4. We have encountered issues with long FHIR package names, however; it seems as though MAXLENs of strings are a little short in HS.FHIRMeta.Storage.Package. Does it make sense to report such issues with a preview edition somewhere? If so, I am happy to provide details on it.
Hi all! Just submitted another one to Open Exchange: https://openexchange.intersystems.com/package/Git-for-IRIS It seems it's still on approval and can't be submitted to the contest yet. Any chance to submit it?
Edit: Published and submitted. 
Hi, also added an announcement: https://community.intersystems.com/post/git-iris-native-git-workflow-ir…
Thanks in advance!
Hi Ben, the project started as a fork of Caché Tortoize Git, which was a good starting point, and initially I intended to change only a few things. As development went on, however, most of the code has been rewritten and I think only 10-20% is left from the original code. There were just too many differences in the basic concepts, including the Globals structure, handling of namespaces and projects, and interaction with Git (hooks -> REST) and Studio (none).
Hi Matthieu,
so you want to use Git for IRIS for an automated export of classes and set it up from the iris.script, which will be invoked in the Dockerfile.
From the code you have pasted, it seems like you use a different Git Source Control implementation (zpm "install git-source-control“). The implementation discussed in this thread would be installed with
zpm "install git-for-iris“There, you can use the API functions in SourceControl.Git.Utils in the iris.script:
do ##class(SourceControl.Git.Utils).AddDefaultSettings()
do ##class(SourceControl.Git.Utils).AddPackageToSourceControl(„<My.Package.Name>“, „<MyNamespace>“)
do ##class(SourceControl.Git.Utils).SetSourceControlStatus(1)A default package is added to source control via module.xml for demo purposes, as well as the /csp/user/sc web application for callbacks from git, both of which you may want to remove.
As a final step, you will have to activate the source control class in IRIS. The manual process is described here https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=A…, you might look into the corresponding CSP page to find out how to do it programatically.
Hope this helps.
It seems that the issue lies in Node.js and that its support for adding trusted CAs is not quite perfect (see e.g. https://github.com/nodejs/node/issues/27079).
The only way I could get it to work was by setting the environment variable
NODE_TLS_REJECT_UNAUTHORIZED to 0
and thus disabling certificate validation entirely in node js.
Btw: Things which looked promising but did not work:
- the http.systemCertificates setting. Node.js in the extension host does not seem to be affected by this setting.
- the http.proxyStrictSSL setting
- the win-ca extension
- the NODE_EXTRA_CA_CERTS env var to add trusted CAs. This would be the preferred way, but I could not get it to work, unfortunately.
Git for IRIS has been updated to v0.3. It now provides source control for lookup tables and supports deletion of classes. Also, improvements were made to provision default settings, and Git hooks are now disabled by default to avoid unwanted side-effects (writing hooks to the .git directory, setting a random password for the technical user).
A complete guide for deploying Git for IRIS to an existing IRIS instance has been added to README.md along with detailed descriptions of settings, Globals and behaviour.