New module : Ignition Git Pro for CI/CD with Github, Gitlab & Gitea

ngonzalez · September 17, 2026, 3:52pm

Hi everyone,

We're happy to announce Git Pro, a new Ignition module from OperaMetrix. It brings real CI/CD to Ignition projects.

Download and try the module on: https://marketplace.operametrix.com

Many of you already version your projects with Git. The hard part is everything after the commit: reviewing changes, testing them, and deploying the same version to dev, test and production gateways without manual exports or copying files around. Git Pro handles those steps.

What it does

Native integration with GitHub, GitLab and Gitea, whether cloud-hosted or self-hosted on your own network
Git workflow in the Designer: commit, push, pull and switch branches without leaving Ignition
Automated deployments: push to a branch or merge a pull/merge request, and the target gateway updates automatically
Pipeline-friendly: runs inside GitHub Actions, GitLab CI or Gitea Actions so you can add checks and approvals before anything reaches production
Environment promotion: the same versioned project moves from dev → staging → production
Full traceability: you always know which commit is running on which gateway, and rolling back is just a Git revert

Chris_Bingham · September 28, 2026, 2:51pm

What is the best place to communicate any issues we find?
Would it be an option to turn on the "Issues" feature on the repo?

We are experimenting with a very large tag provider, and are hitting the static 30 second timeout for reading tags configured within the module:

github.com/operametrix/ignition-git-module

gateway/src/main/java/com/operametrix/ignition/git/managers/GitTagManager.java

f496ce34e


      
          
          for (TagProvider tagProvider : getContext().getTagManager().getTagProviders()) {
              TagPath typesPath = TagPathParser.parse("");
              List<TagPath> tagPaths = new ArrayList<>();
              tagPaths.add(typesPath);
          
              CompletableFuture<List<TagConfigurationModel>> cfTagModels =
                      tagProvider.getTagConfigsAsync(tagPaths, true, true);
              List<TagConfigurationModel> tModels;
              try {
                  tModels = cfTagModels.get(30, TimeUnit.SECONDS);
              } catch (TimeoutException te) {
                  throw new RuntimeException("Timed out reading tag configuration from provider '"
                          + tagProvider.getName() + "' after 30s.", te);
              }
          
              JsonObject json = TagUtilities.toJsonObject(tModels.get(0));
              JsonElement sortedJson = JsonUtilities.createDeterministicCopy(json);
          
              Path newFile = tagFolderPath.resolve(tagProvider.getName() + ".json");

bfreeman · September 29, 2026, 9:53pm

Thank you for bring this issue to that attention. We'll look into it!

I've turned on the issues on the Github repo which is the most convenient place for reporting those indeed.

jakned · October 10, 2026, 7:11pm

Would this work for gateways which are not exposed to internet? All our gateways can reach internet but none of them have public IP.

dkhayes117 · October 12, 2026, 1:14pm

It should. The docs show configuration steps for a local repo.

bfreeman · October 12, 2026, 1:30pm

The requirement is that your Git provider needs to be able to reach your Ignition gateway through the callback that has been configured.

jakned · October 12, 2026, 2:46pm

Ok so in our case, we would need to either expose the gateway to the internet or move the repo from azure or github to on-prem solution. Correct?

pturmel · October 12, 2026, 2:49pm

You could also establish a VPN that solely provides the necessary return path from your git infrastructure.

bfreeman · October 12, 2026, 6:20pm

Although it might be the easiest, I would not recommend exposing your Ignition gateway to internet if that is not already part of the applicative use case. If you still want to go down that path I'd recommend that you setup some network filtering to limit the exposure.

Having everything on-prem would be the ideal solution provided that you don't mind the extra hosting for the Git provider and the extra sys admin work involved.

Also establishing a VPN as proposed by @pturmel unfortunately doesn't seem possible with Github or Gitlab as SaaS.

pturmel · October 12, 2026, 8:14pm

If the callback points at a reverse proxy on the public internet, that only forwards (via VPN) appropriate API endpoints to the actual gateway, then I don't see why they couldn't be made to work.

bfreeman · October 13, 2026, 7:30am

In that case yes! I thought that you were suggesting setting up a VPN on the SaaS Git provider side.

pturmel · October 13, 2026, 12:02pm

I guess that approach would help self-hosted but off-prem--but that wasn't my thought at the time.