Where is the Maven-related documentation?

[acoustic parcel]

In this github issue asking for Gradle support, the author links to a page for Maven, but the link is broken. I didn't find mentions of Maven in the docs manually, and am curious what this linked to before. Does this part of the docs still exist?

[acoustic parcel]

I think I found it from an old PR, if this is what the latest looked like: https://deploy-preview-751--devel-docs-dagger-io.netlify.app/reference/universe/java/maven

[restive dust]

@acoustic parcel exactly, that's from the former CUE only version of Dagger. I think that issue should be revised since we're mostly encouraging users to go the programming SDK's way instead of CUE since those SDK's provide better capabilities to make your CI programmable

re: maven support: which SDK are you looking forward to write your pipelines in?

[acoustic parcel]

@restive dust of the existing SDK langs, I'm most comfortable with Golang, though Python is also possible if we're concerned with wider team adoption. I'm looking at Dagger exploratorily, since at this point while I'm personally enthused about the project, I'm not sure it will solve many of my immediate business needs. I was interested in the mention of Maven from that github thread because I support a primarily Java + Maven stack (main product).

[restive dust]

yes, that makes sense. cc @south goblet @stray bobcat do we have any maven examples around? @acoustic parcel I have a maven example I put together some time ago in Golang that will very likely help you started https://github.com/marcosnils/dagger-libs/blob/main/java/maven.go

[stray bobcat]

We have a gradle example, but it's similar to the maven.go you linked https://github.com/dagger/examples/blob/main/go/gradle-build

[acoustic parcel]

👍 Thanks!

While you're around, a concern a team member of mine had was that by adopting Dagger and trying to reduce the tight integration with our provider (Gitlab CI), that we might make some otherwise simple things unnecessarily complicated -- like the ability to view code coverage results directly in merge requests. 🤔 I haven't used Dagger at all yet, so I haven't tried to solve this, but is this a commonly solved problem?

[restive dust]

@acoustic parcel I wouldn't say it's a "commonly solved problem", but it's something you can definitely do. By any chance are you using Github and actions in your current workflows? Since Github, in contrast to Gitlab, has the tests coverage feature very locked-in to their annotations API.

[acoustic parcel]

No Github usage with us, all Gitlab CI 👍

I don't know how realistic those concerns really are. Esp in the case of what I mentioned above, should just be able to output code coverage reports like any other artifact out of the 1 job that calls Dagger, and it works just as normal.

[restive dust]

if you're using Gitlab CI, in that case is super straightforward since you only need to export your current covertura formatted file from Dagger and that's it. (ref: https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html). LMK if you need some assistance with this and we can help out

[acoustic parcel]

But I'm eager to work through all the cases and see what comes up

[restive dust]

great! don't hesitate to ping here if you have any questions or run into any blockers 🙏

[acoustic parcel]

I just got an update on that -- seems like he was referring to how in order to work with Gitlab specifically, the file has to be a particular format (Cobertura in this case), and that this kind of thing may differ for other platforms (and the whole job could potentially change per platform), which presents a challenge for anything wanting to be a truly generic build system. I will keep an eye out for these kind of platform-specific requirements as I encounter them 🤔

[restive dust]

I think there's a confusion here. If you refactor your pipelines to use Dagger, you'll still need to use Gitlab CI as your CI runners. The idea is that your team an encode all their YAML madness into a programmable pipeline which is then exectued by our engine in an efficient way. However, the platform that runs that engine with its pipelines, needs to be your current CI system

Going back to the coverage situation, if you start migrating your pipelines to Dagger, they'll still run in Gitlab, but Dagger will be the one in charge to generate and export that covertura file so you can continue using it as you do today.

If you run your pipelines locally in your machine, you'll still get the same covertura formatted file locally that you can navigate with any tool of choice.

[acoustic parcel]

Sure, I think I'm actually clear on that. What I think this point was getting at was a response to my pitch of the idea as "portable builds" (docker for CI) that can be moved from one CI provider to another and expected to work the same way. His response point was that there may actually be some integration with the platforms that requires rewrites as you move anyway, unless those differences are all somehow accounted for. I probably shouldn't have mentioned anything until I actually ran through my own hands-on evaluation 🙃

[restive dust]

gotcha. Yeah, of course .. there's always gonna be gotchas (i.e Dagger's ability to leverage the huge ecosystem in github actions it very limited today). Generally those kind features are going to be "cosmetics" around the critical path of your CI which is generally, building, testing, linting, and shipping your software

the ability that you can encode those critical steps in a platform agnostic way is what keeps us moving forward.

[acoustic parcel]

Yep. Avoiding the constant question of "How do I make this CI platform do what I want in this specific case?", because you have all of your natural language constructs available seems very powerful.

Recent use case for me -- I added some functionality to deploy branch code to ephemeral environments from MRs (via manual action in Gitlab CI), but I also wanted a cleanup job that could run periodically. You can define matrices of targets for Gitlab CI jobs, but unfortunately you cannot define dynamic targets, so I couldn't straightforwardly evaluate what AWS environments were eligible for cleanup and target each of those with an undeploy job. The Gitlab CI way to solve this is to use another previous job to dynamically generate the whole YAML config for the cleanup job 🤢

I mean it would work, but that seemed so ugly. That was my first thought of a use case for Dagger.

[restive dust]

yep, totally makes sense. It's particularly in this dynamic situations where users generally prefer using the convenience of a programming languate to encode this logic in code and be able to test it and run it locally as well