CI/CD Arch Unit massive use

[gdcmarinho]

I've been working with the idea of testing all new source code projects from my company with the Arch Unit. These projects needs to have a standardized architecture. Reading the documentation, I didn't find any useful information about how to test components hidding the tests from developers (the only solution that I found was this topic on StackOverflow).

I don't want to show the rules and tests for developers, including not allowing changing them. What are the possible solutions to this problem? Should I create a stage where these tests are injected in the code temporarily and execute the test?

[gdcmarinho]

@codecholeric @hankem

[nbrugger-tgm]

I think what you can do is creating a new (sub?) project (maven or grade) and pulling in the Code to test as a dependency, since ArchUnit scans the whole classpath using a Dependency does the Trick. Then in this subproject/repository you can define your rules and have seperate access permissions for the rule project

[codecholeric]

Hey, one possibility would also be to include it into your CI/CD pipeline on an artifact level 🤔 I.e. all the JARs produced on CI are passed on to some other job in the pipeline that does effectively

JavaClasses classes = new ClassFileImporter().importJar(producedJar);
// evaluate all rules on producedJar

Could also just have a determined input folder and check all the JARs in there, so the pipeline job would be independent on the concrete projects and would not need to update dependencies, etc., but whatever the previous job supplies as input will be checked 🤷‍♂️

Otherwise you can follow the approach that @nbrugger-tgm mentioned, e.g. create a project where you depend on the produced artifacts from your artifact repository (e.g. Nexus). But then you need to either create the dependencies dynamically or update that project when new projects to test pop up.

For further ideas I would probably need some more constraints 😉 Like how do you imagine it to be integrated into your CI? Do you imagine a separate job like outlined before or are you looking for some fully transparent injection into the project under test (which will likely only work if you have a fairly standardized build system for every project)

[gdcmarinho]

I solved creating a Quarkus library with Arch Unit as dependency and a simple test architecture class. Then I import this library as a dependency in the project, and add the test scope (then everytime my Quarkus service is started, a new test archicture verification is done). Thank you so much for the tips!

[gdcmarinho]

Also, I'd like to request some content about it in the Arch Unit documentation. This tutorial could help a lot of other software developers.

[codecholeric]

I'm happy that you could solve your problem 😃 I'm also very open about adding a section to the docs, since the question about distribution of ArchUnit rules comes along every now and then again. The question is, what exactly should go in there 🤔

Should it be a section titled "Distributing Architecture Rules" and then simply outline that you can package your ArchUnit rules in a separate project as a JAR and then put it on the classpath as a dependency? The problem I see is that how to run these tests then is somewhat environment specific 🤔 You say for Quarkus you just add a JAR to your classpath that contains an ArchUnit test class and it is automatically executed? Because I'm fairly sure that e.g. for a standard Maven project it's not that simple and you have to somehow configure that tests from that JAR are also executed (and not only tests directly contained in this project). And documenting all these environment variations is probably out of scope again then...

[gdcmarinho]

Well, I just tested it in the Quarkus environment, but we can generate an application based in Spring Boot and perform the same experiment to see if it works too. What do you think? I'll create the repository and invite you.

By the way, in my tests this experiment needed that the source code to be tested needs to be at the same group and artifact level as the jar. Probably there is a better way to do the same.

[codecholeric]

Sure, we can try this out in a little experiment to see what is necessary 👍