Pravin Barton · Apr 26, 2024 go to post

We found a way to do the second part, importing the class from a file without overwriting a specific member. The trick is:

  • open the old class definition with ##class(%Dictionary.ClassDefinition).%OpenId("class name")
  • create a clone with %ConstructClone()
  • load the class from the file without compiling it
  • open the new class definition
  • copy the member you want (in this case production definition XDATA) from the clone to the new class definition, and save the new class definition
  • finally, compile the class.
Pravin Barton · Jul 16, 2024 go to post

Hello Reuben,

You're correct that a single namespace can only have a single branch checked out at a time with git-source-control. The reason is that the namespace has one Git repository, and a Git repository cannot have multiple branches checked out at the same time.

I would consider this a feature rather than a bug. Imagine that a single namespace was associated with multiple branches, and an item has different changes on each branch. Which branch's version of the item would get loaded into IRIS? Shared development environments require there to be a single source of truth for the state of every item in source control.

For your scenario I might suggest single-user development environments. You could create a separate namespace for each developer on your server. Each namespace would have its own repository, with its own branches, cloning the same remote repository. The downside is that if two users edit the same item in different namespaces, you can end up with merge conflicts that you will need to resolve. I would highly recommend single-user environments if your developers are already comfortable with Git.

Pravin Barton · Jul 29, 2024 go to post

You might use a GitLab webhook to do this. The first step would be to create an endpoint on your IRIS environments that can be called over HTTP to run the Pull method of the git-source-control API. That will deploy a change by running "git pull" and loading the changed files into IRIS. A simple way to do that is by creating a new web application with a REST handler like this:

Class MyApp.PullHandler Extends%CSP.REST
{
ClassMethod Pull()
{
    do##class(SourceControl.Git.API).Pull()
}
XData UrlMap
{
<Routes>
<Route Url="/pull" Method="POST" Call="Pull"/>
</Routes>
}

You will also need to make sure that this endpoint is network accessible to your GitLab environment, and authenticated according to your security requirements.

The second step would be to configure a GitLab webhook to call this endpoint on the event of a PR being merged. Here is some documentation from GitLab about how to do that: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html

Hi Armin, which version of the Embedded Git plugin is running on your server? If you have IRIS terminal access, the following command will show the version:

zpm "list-installed git-source-control"

Try the following:

set mylist = ""for i = 1:1:5 {
    set item = "item"_i
    set mylist = mylist _ $ListBuild(item)
}

zw mylist

$Listbuild lists have a separator that includes the length of the data in the next item of the list. This is why your original code wasn't working - $listbuild(mylist, item) would make a new list with two elements where the first item was the original list.

You might be able to use the Size property to keep track of the initial size of the stream, write some more data, then use MoveTo() to rewind back to where you started writing:

set stream = ##class(%Stream.FileCharacter).%New()
do stream.Write("hello world!")
set tmpSize = stream.Size
do stream.Write("goodbye world!")
do stream.MoveTo(tmpSize + 1)
write stream.Read()

Hi Paul,
There are a couple different ways of doing source control with IRIS and git.

The first is client-side source control. You will have a git repository on your local machine. You use VS Code to edit files in that local git repository. The ObjectScript extension for VS Code will push those edits to the IRIS database. You can then commit those changes and push them up to GitHub/GitLab/etc. using the git CLI locally or whatever git tool you prefer.

The second is server-side source control using Embedded Git. You will have a git repository on the remote server that IRIS is running on. That git repository can be created with `##class(SourceControl.Git.API).Configure()`. You can use VS Code with ISFS (or Studio, or the Interoperability Portal) to edit code in the IRIS database. Embedded Git will export that code to the git repository for you. You can then commit and push those changes using the source control menus embedded into IRIS.

It sounds like you have a mix of both currently which can get chaotic.

The advantage of client-side source control is that it's closer to standard industry practices. There are a lot of helpful tools like GitLens and GitHub Desktop that rely on you having a local git repository.

There are a couple of advantages of server-side source control:
- If you have multiple developers editing code in the same namespace (pretty common with legacy IRIS users) it will prevent them from stepping on each others' toes.
- If you are doing most of your work in the IRIS interoperability editors, server-side source control gives you source control actions embedded directly in those editors.
  
  Let me know if this is helpful or you have other questions.

> Where in IRIS?

If you have VS Code set up with server-side (isfs) editing, there will be a little source control icon in the upper right corner when you open an item for editing:

The same icon will show up in the System Management Portal when you're editing an item that can be source controlled, for example in the production configuration page or the data transformation builder.

Note that these icons will only show up if server-side source control is enabled for the namespace, which `##class(SourceControl.Git.API).Configure()` will do for you automatically.

> Is there some easy to follow tutorials for both solutions?

This isn't a full tutorial but the best I can recommend for now is this video: https://community.intersystems.com/post/video-selecting-right-source-co…