#jenkins
1 messages · Page 1 of 1 (latest)
well well well, this seems like someplace I should be
(I do more Jenkins than I like lol)
I've been building the Dagger vision into a Python script, i.e. it should work locally like it does in CI, so our Jenkins jobs just run this script now.
The one thing holding us up from adopting Dagger is (1) our python version (3.9 < 3.10 required) or (2) deciding to run the Go SDK from python (via exec)
đź‘‹
Are you pinned to 3.9 right now because of an organizational policy or because of an app compat issue?
it's more about the underlying OS version, on the redhat-ish train, so things are behind?
We're technically on 3.6 right now, but will have 3.9 with the next update, 3.10 is not on our radar
org policy is just one, consistent operating system for everything
@vocal osprey how do Zenith modules come into play with SDK versions in a case like this? Not everyone is going to be able to use the same version of Python, for instance.
@lethal dirge - check out #1126283128143626300 too!
Yeah, the version of Python on the host won't matter anymore. You'd just need the dagger binary, which runs its own version of Python. (Currently hardcoded, we need to figure out how that should be configured.)
How do you all use dagger in Jenkins? Do you still make use of the plugins in Jenkins or do you have switched as much as possible to dagger?
Mix of both, Jenkins plugins for configuring jobs and events (GitHub|GitLab, cronjobs, etc...), and configuring nodes (baremetal, k8s, cloudstack), then run the ci logic with dagger, sometimes I have to add additional logic in groovy to deal with CI feedback or utilize multiple nodes where each node will run parametrized dagger code
The Dagger docs show a basic implementation for calling your Dagger pipeline. I want to add an end-to-end video and example in the not-too-distant future. There are some good examples on YouTube of when Dagger was CUE-based, but we need an updated example with the multi-language Dagger SDKs. Several people are working on and discussing a #java SDK. Java with Dagger modules (see #daggernauts ) are analogous in many ways to Jenkins plugins and pipeline shared libraries.
does anyone know of a more production ready version of this pipeline? https://docs.dagger.io/integrations/322019/jenkins
hey Felix! what are you looking for particulary? In the end it boils down to making Dagger function calls
Hello đź‘‹
We've been noticing some issues in Dagger Cloud for displaying traces ran in Jenkins
It seems like the Git metadata we use to set the origin of a trace is incomplete when running Dagger in Jenkins. There is a workaround for this, and we are updating our documentation for it here: https://github.com/dagger/dagger/pull/7776/files
Thanks @next elbow for taking the lead on this!
FYI this is a workaround, and we are looking for ways to avoid adding extra configuration to your pipelines to display traces properly in Dagger Cloud
We'll cover Jenkins use cases in our community call tomorrow. Come to watch the demo and ask all your questions 🙂 #general message
In this demo, Lev Lazinskiy shows how to integrate Dagger pipelines with Jenkins. He explains the setup process for a Jenkins pipeline using Dagger and covers both a simple and a modular approach to managing CI pipelines effectively.
Do you have questions about how to do this for your pipelines? Join the Discord server, and our community will ...
My work setup requires running Jenkins builds inside ephemeral K8S pods https://plugins.jenkins.io/kubernetes/ - here's a snippet of the Jenkinsfile...
stage('dagger') {
agent {
kubernetes {
defaultContainer 'dagger'
label "${BUILD_LABEL}-dagger"
yaml <some-pod-with-dagger-container from registry.dagger.io/engine:v0.14.0>
}
}
stages {
stage('Build') {
steps {
sh '''
dagger version
dagger call ruff --config ./ruff.toml --directory .
'''
}
}
This works perfectly fine.. apart from it's just ...too... slow -
+ dagger version
dagger v0.14.0 (registry.dagger.io/engine:v0.14.0) linux/amd64
+ dagger call ruff --config ./ruff.toml --directory .
1 : connect
2 : connecting to engine
2
2 : connecting to engine DONE [0.0s]
1 : connect DONE [0.0s]
3 : loading module
4 : finding module configuration
4 : finding module configuration DONE [0.2s]
5 : serving module
6 : inspecting module
5 : serving module DONE [1m35.5s]
6 : inspecting module DONE [0.3s]
3 : loading module DONE [1m36.1s]
The "loading module" stage is a fixed cost of 1m30 / 2m for each new build. When run with the --debug flag I see all the codegen happening underneath - is there anyway to avoid this startup time? Using the Python SDK so far if that matters.
I wonder if it has something to do with Python. I do this too and the loading (including image pull) happens in like 20s (Which is acceptable to me). I do a dagger core version to pre-"warm" the engine where it pulls the image and starts the engine container. I am using the Go sdk though.
If k8s, daemonset dagger setup might ease up the “engine warmup” https://docs.dagger.io/integrations/kubernetes
Thank you, I have requested that & I'm sure it will help.
Hello Everyone,
I’m new to Dagger, I wonder if I can use Dagger to run my Jenkins/Groovy pipelines or if I have to rewrite them all in another language ? Does anyone know the answer ?
Thanks for your help guys !
Hi @hallow merlin , the answer is you should rewrite your pipelines in another language with sdk there are a lot languages
Here an example https://github.com/robertonav20/dagger-modules
Hello is there a way to remove these dagger timestamp logs when displaying in Jenkins, for example
32m+[0m[0m {
[32m+[0m[0m config = {}
[32m+[0m[0m name = ...
},
For example in terraform output logs
try DAGGER_PROGRESS=logs or pass --progress=logs to the CLI. I use dagger in Jenkins too 🙂