OAC GitHub CI/CD integration

Branden Pavol · Jan 22, 2026 5:10PM

In the Web Semantic Layer, there is GitHub integration. When it comes to OAC objects (connections, datasets, visualizations), there is no easy way to version control these and migrate them between environments. We would like to eliminate the "development" in production. We want people doing their development in a non-prod. This could be some lightweight reporting or bigger dataset or new dashboard development. In order to do that migration, you need to either move the entire bar file or do individual copy/paste of JSON or try the export/import method. All of those options are either manual or potentially dangerous. There needs to be an easier way to control the versioning of content in OAC.

Seth Hobbes · Jan 22, 2026 5:15PM

This is very much needed, and given that all objects in the BAR file seem to be mostly JSON/XML, I would assume this is a feasible request. While a simple short-term solution might be to integrate with GitHub across environments, I would think that it would be even more beneficial to allow branching directly within OAC itself, effectively having "local" copies of your origin (GitHub) branches. This would be a nice feature for the WSM as well, since currently you can only have 1 WSM/RPD deployed at any given time, it's impossible to test your WSM development within the prod environment.

peacey · Jan 22, 2026 7:52PM

Agree completely with this - needs to be a lot easier. Current best option for workbooks seems to be using CLI for archive/unarchive. So check a .catalog file into Git and use this in the pipeline. And use datamodel upload to deliver rpd.

mohammad-rafi-ansari-Accenture · Jan 26, 2026 2:30PM

I strongly support the OAC GitHub CI/CD integration idea raised by Branden, as this capability is absolutely essential. I fully agree with Branden’s assessment—this is a critical requirement for our clients and for the broader OACS user community.

The ability to deploy OACS catalog objects seamlessly from one environment to another is crucial. Today, manually promoting changes from lower to higher environments is extremely time-consuming and error-prone once the code is ready.

Expediting this functionality would significantly improve developer productivity, streamline deployments, and benefit everyone using the OACS product worldwide

Thanks!