An OCL GitHub action to validate models in your CI/CD pipelines

Modeling in the real world

I love modeling, from roughly sketching interactions of my components on my notebook to formalizing my application’s business logic using UML and OCL. It feels good to abstract out complex structures, generate code, automatically check constraints, etc.

It’s not really a surprise, I am a believer in MDE. But I am also a pragmatic guy, and I’ll try to use the best tools in my toolbox for the task I am working on. Create models and metamodels: EMF, define and check constraints: OCL, present my application through a REST API: Spring, store data from my application: Databases.

These are the tools in my toolbox: I don’t claim they are the absolute best solutions, they are just the ones I am the most confident with.

My projects usually end up as a matchup of MDE-based stuff and more traditional Java bits. A good example of that is Xatkit for e-commerce: a core model-based execution engine wrapped in a Spring application, with a database storing logs and execution traces.

So far so good, but there is this inevitable moment when I want to automate how these projects are built using CI/CD, and this is where things become complicated. The MDE tools I use are based on Eclipse, and they don’t integrate well with traditional Java build tools and workflows. To keep it simple, these tools really want you to stay within the realm of Eclipse, and they don’t operate well if you try to make them work standalone, e.g. in the context of a build script.

If you are familiar with this ecosystem, you have probably worked with Tycho, which allows building Eclipse plugins with maven. Tycho solves a lot of problems, but there are still some tasks that are painful to make work:

• How do you generate code from an ecore/genmodel file with maven?
• How do you check OCL constraints as part of your build?
• How do you wrap your generated EMF plugins into jars you can reuse in other parts of your application?

Don’t get me wrong: there are probably solutions for all these problems, but they aren’t easy to find. There are dozens of posts on the Eclipse forums related to EMF code generation with maven, e.g. this one from 2008, or this other one posted a decade later. The solutions I find often look a bit hackish, and I always feel I am doing something wrong when I have to write hundreds of lines of maven configuration to make my damn build work.

What I’d like to have here is a maven plugin to generate EMF code, or an OCL Github action I can add to my workflow to check constraints as part of my build.

It’s also fair to acknowledge that there are amazing initiatives to port MDE tools to the maven world. Xtext is well integrated with maven, and there are some examples of code generation from xcore models available on Github.

OCL Github Action to the rescue

So I was once again working on a CI/CD pipeline for my MDE application, and this time I needed to validate a set of OCL constraints against a model as part of my build. I spent some time looking around for the best way to do it, but I wasn’t really satisfied with the solutions, so I decided to build a Github action for that.

I had the following requirements:

1. I have a metamodel in my repository
2. I have an OCL file with additional constraints defined on my metamodel
3. I have a model that conforms to the metamodel
4. I want to make sure that when I push a new version of my model the constraints are validated against it.

The complex part to build this action wasn’t the constraint validation itself: the OCL documentation provides many useful examples for that, and it’s relatively easy to programmatically check constraints over a model. The hard part was to provide a standalone jar the CI/CD pipeline could invoke to run the validation. And obviously I wanted to setup a CI/CD pipeline to automatically build this standalone jar ???? So I was back in the realm of Tycho and complex build configuration, but this time I’d do it once and for all!

I managed to make it work by reusing examples from the Unveiling project, which is a collection of (outdated) mavenized Eclipse plugins that produce standalone jars including all the required dependencies. I am not sure this is the best way to do it, but it does the trick for me.

Next step: package my jar into a Docker image, so the Github action framework could start it as a container and run the validation. To do so, I basically followed this tutorial, and adapted the image to my application’s requirements.

And that’s it! I now have a Github action I can use in all my workflows to automatically validate models! Here is an example of such workflow using the action to check constraints on a demo project.

The action requires 3 parameters:

• metamodel (required): the location of the metamodel file
• model (required): the location of the model file
• constraints (required): the location of the OCL file containing the constraints to check

Models with unsatisfied constraints make the workflow fail, and the logs contain details on which constraint(s) was violated, and for which model element(s).

What about a maven integration?

Github actions provide numerous benefits, but they also have some limitations. Obviously, you can’t use them if your project isn’t stored on Github, but they also require you to push your new model to validate the constraints, you don’t have an easy way to do it locally.

A maven integration could solve these issues: you’d configure a plugin as part of your maven build to take care of the validation, and the build would fail if the constraints aren’t satisfied. This way you could validate your models locally with maven, but also as part of a CI/CD pipeline assuming it provides support to maven builds, which shouldn’t be too hard to find.

There is a validate phase in maven’s build lifecycle, I guess this is a good phase to validate models ????

This is something I’d like to explore, but to be honest I don’t have a lot of experience with building maven plugins. I guess it’s time to learn something new!

Next steps

There are a bunch of things I’d like to work on with this action. First, I have some cleaning to do with the way the docker image is built. For now, it’s rebuilding the standalone jar from scratch every time the action is invoked, which takes a lot of time and resources. It would be better to fetch a stable version from a repository (e.g. maven central) and skip all the compilation/building steps.

I am also wondering how to integrate the multiple releases of OCL in the mix. So far I am using the OCL plugins released with Eclipse 2022-03, but it would be nice to let the user specify which release they want to use. I am also worried on how I can keep up with future releases.

I am thinking about new features I could add to the action, such as supporting several OCL files, inline definition of constraints as part of the workflow, or supporting alternative formats of metamodels like xcore. And I definitely want to explore the maven plugin thing I mentioned above! All this moving towards a more ambitious and generic goal of continuous model-driven engineering.

I hope this OCL Github action can be helpful for you. If so, do not hesitate to give the project a star, it’s always nice to feel supported! And as usual, I’d be happy to read your opinion on this work in the comments.