#general

1 messages · Page 16 of 1

autumn swallowBOT
#

Welcome @stiff sandal!

mild scarab
#

Thanks for the meetup and for the answers, 🚀

turbid tulip
autumn swallowBOT
#

Welcome @topaz hill!

#

Welcome @nimble thistle!

#

Welcome @jaunty folio!

#

Welcome @crimson prawn!

#

Welcome @sturdy laurel!

balmy wolf
#

congrats on the launch!!

jaunty folio
#

Would love to be a part of dagger's journey if you are accepting interns too.

autumn swallowBOT
#

Welcome @wispy sluice!

#

Welcome @proud ermine!

winter linden
winter linden
rustic shard
autumn swallowBOT
#

Welcome @cloud helm!

#

Welcome @robust tundra!

#

Welcome @glacial sorrel!

#

Welcome @covert iron!

#

Welcome @vivid lake!

#

Welcome @upbeat lava!

#

Welcome @dull copper!

#

Welcome @azure forge!

#

Welcome @tacit halo!

#

Welcome @celest cargo!

#

Welcome @blissful garnet!

#

Welcome @heady viper!

winter linden
#

Hi everyone! We are here to answer any questions. The documentation is still a work in progress... If you are missing information we will gladly fill the gap here.

autumn swallowBOT
#

Welcome @swift barn!

#

Welcome @hexed prawn!

#

Welcome @thin pulsar!

#

Welcome @winged radish!

#

Welcome @uncut hatch!

#

Welcome @swift barn!

#

Welcome @eager blade!

#

Welcome @faint sleet!

blissful bone
#

Hi there
I finally found the time to get back to dagger
Last time i launch dagger it was v0.1
Need time to adapt to this new release 😄

autumn swallowBOT
#

Welcome @past star!

#

Welcome @strange current!

#

Welcome @livid vigil!

winter linden
#

@blissful bone welcome back 🙂 If you need to migrate a 0.1 config, we are here to help!

blissful bone
#

thanx @winter linden
I'm going to restart from scratch
I have some use case to test

autumn swallowBOT
#

Welcome @sonic adder!

#

Welcome @floral bison!

#

Welcome @austere dome!

#

Welcome @latent terrace!

#

Welcome @scenic mortar!

austere dome
#

Congrats guys

mystic mantle
#

Thanks @austere dome dagger

autumn swallowBOT
#

Welcome @limpid cipher!

#

Welcome @swift barn!

#

Welcome @granite sail!

#

Welcome @tawdry latch!

#

Welcome @elfin marsh!

#

Welcome @broken bough!

#

Welcome @devout helm!

#

Welcome @paper flint!

#

Welcome @autumn thistle!

#

Welcome @crystal fog!

#

Welcome @strong ingot!

winter linden
autumn swallowBOT
#

Welcome @loud birch!

#

Welcome @swift barn!

vestal creek
#

Congratulations on the launch, exciting times ahead ❤️

turbid tulip
autumn swallowBOT
#

Welcome @queen thicket!

#

Welcome @polar pine!

#

Welcome @cursive merlin!

autumn swallowBOT
#

Welcome @wheat blade!

#

Welcome @tepid robin!

#

Welcome @shy surge!

#

Welcome @jolly fable!

#

Welcome @swift barn!

winter linden
autumn swallowBOT
#

Welcome @stable brook!

#

Welcome @next wigeon!

#

Welcome @turbid relic!

#

Welcome @dapper galleon!

#

Welcome @tender anchor!

#

Welcome @tribal swallow!

#

Welcome @delicate dirge!

#

Welcome @charred anchor!

#

Welcome @unborn mango!

#

Welcome @hexed ridge!

#

Welcome @proper elk!

#

Welcome @summer geyser!

#

Welcome @hot pine!

#

Welcome @merry current!

#

Welcome @swift barn!

#

Welcome @severe pike!

#

Welcome @tardy copper!

#

Welcome @swift barn!

#

Welcome @pliant arch!

#

Welcome @bright pulsar!

autumn swallowBOT
#

Welcome @wide wadi!

#

Welcome @swift barn!

#

Welcome @robust kernel!

#

Welcome @bitter gulch!

#

Welcome @merry wedge!

#

Welcome @swift barn!

merry wedge
#

wassup

autumn swallowBOT
#

Welcome @drifting valley!

#

Welcome @autumn wren!

#

Welcome @sage night!

#

Welcome @kindred imp!

#

Welcome @latent pivot!

#

Welcome @upper reef!

#

Welcome @elfin stag!

#

Welcome @devout bluff!

#

Welcome @indigo trail!

#

Welcome @vital pond!

#

Welcome @strong isle!

autumn swallowBOT
#

Welcome @iron flower!

#

Welcome @knotty solar!

#

Welcome @strong raptor!

#

Welcome @shadow mulch!

#

Welcome @lapis bolt!

#

Welcome @broken bear!

#

Welcome @fluid sinew!

#

Welcome @fast geode!

#

Welcome @frigid otter!

#

Welcome @tired helm!

distant pebble
#

Congrats on the official launch team 🚀

autumn swallowBOT
#

Welcome @swift barn!

#

Welcome @compact fog!

#

Welcome @lethal canopy!

#

Welcome @wicked dove!

#

Welcome @stable stratus!

#

Welcome @sharp blaze!

muted gale
#

The docs are pretty nice

autumn swallowBOT
#

Welcome @woeful mulch!

#

Welcome @sage coyote!

#

Welcome @rain condor!

#

Welcome @strange hearth!

winter linden
autumn swallowBOT
#

Welcome @next widget!

#

Welcome @red zodiac!

#

Welcome @icy tartan!

#

Welcome @swift barn!

#

Welcome @fathom lantern!

#

Welcome @atomic nest!

#

Welcome @brazen plover!

#

Welcome @quartz granite!

#

Welcome @wet arrow!

#

Welcome @wispy island!

muted gale
#

@winter linden I remember there being some documentation on the goal of dagger universe, which I cant find on the new docs. I want to write a bit about Dagger and would like a first party reference

autumn swallowBOT
#

Welcome @haughty moat!

#

Welcome @potent gulch!

#

Welcome @hard zephyr!

#

Welcome @bold moss!

#

Welcome @errant lance!

#

Welcome @west bluff!

west bluff
#

I've just skimmed through the dagger website and I'm wondering how different its gonna be from something like ansible or terraform

#

Heck, maybe pulumi?

wraith niche
autumn swallowBOT
#

Welcome @stone osprey!

#

Welcome @hushed gale!

#

Welcome @ivory zinc!

#

Welcome @true marsh!

#

Welcome @crude barn!

#

Welcome @carmine knoll!

#

Welcome @candid sparrow!

#

Welcome @surreal sparrow!

#

Welcome @mint rampart!

#

Welcome @vagrant vault!

#

Welcome @humble token!

#

Welcome @nocturne surge!

#

Welcome @cedar condor!

#

Welcome @fiery condor!

#

Welcome @swift barn!

#

Welcome @tender ginkgo!

#

Welcome @winged latch!

#

Welcome @fallen pewter!

#

Welcome @civic atlas!

#

Welcome @sweet grail!

#

Welcome @dusky inlet!

#

Welcome @heavy fiber!

#

Welcome @slate wasp!

#

Welcome @mortal socket!

#

Welcome @coral fjord!

#

Welcome @harsh harbor!

#

Welcome @worldly cobalt!

#

Welcome @keen canopy!

#

Welcome @foggy perch!

#

Welcome @vapid stag!

#

Welcome @sage whale!

#

Welcome @muted marten!

#

Welcome @unborn citrus!

#

Welcome @hasty silo!

#

Welcome @west hawk!

#

Welcome @viscid burrow!

#

Welcome @dusk lance!

#

Welcome @wild light!

#

Welcome @solid oxide!

#

Welcome @astral smelt!

#

Welcome @woven trout!

#

Welcome @sonic minnow!

#

Welcome @royal oak!

#

Welcome @icy fjord!

#

Welcome @grizzled fable!

#

Welcome @void swan!

#

Welcome @cloud kettle!

#

Welcome @astral moss!

winter linden
#

We might have to disable that auto-welcome bot soon 😅

Welcome everyone.

autumn swallowBOT
#

Welcome @left falcon!

#

Welcome @sweet patio!

#

Welcome @steep sequoia!

#

Welcome @ocean mural!

#

Welcome @ruby tinsel!

#

Welcome @restive void!

#

Welcome @shell juniper!

#

Welcome @dense rampart!

steep sequoia
autumn swallowBOT
#

Welcome @novel frost!

#

Welcome @gaunt timber!

#

Welcome @frozen basin!

#

Welcome @full dome!

#

Welcome @ember thorn!

#

Welcome @digital dawn!

#

Welcome @urban kettle!

#

Welcome @dusky oak!

#

Welcome @strong finch!

#

Welcome @calm nebula!

#

Welcome @vast violet!

#

Welcome @dense lion!

#

Welcome @stray cloud!

#

Welcome @sly finch!

#

Welcome @arctic geyser!

arctic geyser
#

Seriously, why “Dagger”?

https://dagger.dev

Dagger

Dagger is a fully static, compile-time dependency injection framework for both Java and Android. It is developed by the Java Core Libraries Team at Google.

autumn swallowBOT
#

Welcome @rancid terrace!

#

Welcome @errant drum!

#

Welcome @opal snow!

#

Welcome @thorn surge!

#

Welcome @barren quiver!

#

Welcome @swift barn!

#

Welcome @amber adder!

#

Welcome @hasty cosmos!

#

Welcome @dense pollen!

#

Welcome @wind coral!

#

Welcome @sour ivy!

#

Welcome @whole barn!

#

Welcome @near python!

#

Welcome @vocal crane!

silk apex
autumn swallowBOT
#

Welcome @edgy swan!

#

Welcome @finite agate!

#

Welcome @oblique portal!

#

Welcome @swift barn!

#

Welcome @swift barn!

#

Welcome @silent oak!

#

Welcome @hazy phoenix!

#

Welcome @frank heart!

#

Welcome @past spindle!

#

Welcome @vale flower!

#

Welcome @wicked pivot!

#

Welcome @charred dragon!

#

Welcome @red violet!

#

Welcome @clever blaze!

#

Welcome @opaque agate!

#

Welcome @modest fossil!

#

Welcome @little sky!

#

Welcome @thin tartan!

#

Welcome @oblique mural!

#

Welcome @plain grail!

#

Welcome @upbeat nimbus!

#

Welcome @fast zodiac!

#

Welcome @random hornet!

#

Welcome @main basin!

#

Welcome @swift barn!

#

Welcome @tardy birch!

#

Welcome @swift barn!

#

Welcome @unborn tundra!

#

Welcome @cedar hearth!

#

Welcome @swift barn!

#

Welcome @sullen wyvern!

#

Welcome @swift barn!

#

Welcome @woeful beacon!

#

Welcome @somber kiln!

#

Welcome @outer meteor!

#

Welcome @quiet obsidian!

#

Welcome @inner salmon!

#

Welcome @alpine pagoda!

#

Welcome @olive crater!

#

Welcome @zealous minnow!

#

Welcome @stark ermine!

#

Welcome @river thorn!

#

Welcome @honest lichen!

#

Welcome @urban harness!

#

Welcome @vast dome!

#

Welcome @pulsar estuary!

#

Welcome @neat needle!

#

Welcome @proven kestrel!

#

Welcome @magic fjord!

#

Welcome @quasi moss!

#

Welcome @foggy token!

#

Welcome @dusk ridge!

#

Welcome @sour shell!

autumn swallowBOT
#

Welcome @bright umbra!

#

Welcome @swift barn!

#

Welcome @keen holly!

keen holly
#

so i was interested in what the helm integration looked like, but it seems that iwas only in dagger 0.1 is that right?

#

im also curious how it would look to use dagger w/ a gitops based flow with something like argocd. atm it seems dagger is responsible for applying manifests to the k8s API.

autumn swallowBOT
#

Welcome @swift barn!

#

Welcome @ocean herald!

somber kiln
keen holly
#

yeah, im trying to think of what I would want it to look like, but im not sure yet. a big benefit is the coupling between build+deploy, but we all know it's often necessary to decouple those bits, but still keeping it streamlined is important.

rain oriole
rain oriole
keen holly
#

i suppose in a gitops flow i would have a pipeline like this:

  • build image
  • deploy == "update a manifest/config with the image tag/git commit" + "git commit && git push". so a dagger action could be some form of that either using shell or something that would understand updating dagger configs directly, plus the git aspect.

then

  • argocd gets triggered via the update to the git repo
  • runs a 'dagger' plugin that renders the YAML in the repo

something like that maybe.

keen holly
autumn swallowBOT
#

Welcome @neon mantle!

#

Welcome @steady kayak!

#

Welcome @blazing hound!

rain oriole
keen holly
#

id rather avoid building them and saving them to the repo, but it's not a terrible idea, as having fully rendered out manifests makes it easier to see what changed.

#

but in practice that doesn't work well when everything is in the app repo. also it tends to balloon repo sizes quite fast and that has it's own issues.

autumn swallowBOT
#

Welcome @wheat storm!

blazing hound
#

is there a comparison between dagger and other ci/cd tools ?

swift inlet
autumn swallowBOT
#

Welcome @swift barn!

blazing hound
swift inlet
autumn swallowBOT
#

Welcome @fathom sierra!

blazing hound
autumn swallowBOT
#

Welcome @shy wharf!

#

Welcome @swift barn!

#

Welcome @unborn halo!

swift inlet
autumn swallowBOT
#

Welcome @placid sapphire!

#

Welcome @cold frigate!

#

Welcome @south isle!

loud glade
#

@winter linden any thoughts around secure supply chains and SLSA (https://slsa.dev/) and dagger ? (integrations, slsa levels, …)

autumn swallowBOT
#

Welcome @broken junco!

#

Welcome @hollow vector!

#

Welcome @vivid granite!

#

Welcome @tawny cloak!

#

Welcome @swift barn!

#

Welcome @fallow hound!

#

Welcome @dusty anvil!

#

Welcome @valid glade!

#

Welcome @daring fog!

#

Welcome @slim hatch!

#

Welcome @swift barn!

#

Welcome @deep totem!

#

Welcome @buoyant bloom!

#

Welcome @normal stone!

#

Welcome @finite flame!

#

Welcome @ivory dagger!

#

Welcome @hoary otter!

#

Welcome @abstract pebble!

#

Welcome @hardy geode!

#

Welcome @azure shard!

#

Welcome @teal sage!

#

Welcome @humble berry!

#

Welcome @swift barn!

#

Welcome @wintry dust!

#

Welcome @swift barn!

#

Welcome @faint vortex!

#

Welcome @round acorn!

somber kiln
#

I would be interesting in seeing what Pipelines everybody uses. I am tired of Jenkins. I've grown to hate it.

autumn swallowBOT
#

Welcome @uneven dust!

#

Welcome @stuck summit!

#

Welcome @delicate oyster!

swift inlet
autumn swallowBOT
#

Welcome @solid gorge!

#

Welcome @desert stirrup!

#

Welcome @idle vessel!

#

Welcome @proven bronze!

#

Welcome @tranquil hill!

#

Welcome @tough radish!

#

Welcome @honest wing!

#

Welcome @copper briar!

#

Welcome @cloud socket!

mild scarab
autumn swallowBOT
#

Welcome @tawdry grove!

#

Welcome @fresh iris!

#

Welcome @alpine wing!

abstract pebble
#

👋 Hello! After reading https://docs.dagger.io/1201/ci-environment, I was wondering if Dagger could take advantage of the parallelization features of existing CI/CD systems; e.g. by transpiling to the native workflow syntax:

Dagger

(generic code that translates to the specification below)

GitLab CI/CD

one:
  when: manual
  script:
  - echo one
two_a:
  needs: [one]
  script:
  - echo two_a
two_b:
  needs: [one]
  script:
  - echo two_b
three:
  needs: [two_a, two_b]
  parallel:
    matrix:
    - PART: [1, 2, 3]
  script:
  - echo three $PART

GitHub Actions

on: workflow_dispatch
jobs:
  one:
    runs-on: ubuntu-latest
    steps:
    - run: echo one
  two_a:
    needs: one
    runs-on: ubuntu-latest
    steps:
    - run: echo two_a
  two_b:
    needs: one
    runs-on: ubuntu-latest
    steps:
    - run: echo two_b
  three:
    needs: [two_a, two_b]
    strategy:
      matrix:
        part: [1, 2, 3]
    runs-on: ubuntu-latest
    steps:
    - run: echo three ${{ matrix.part }}
autumn swallowBOT
#

Welcome @peak anchor!

#

Welcome @swift barn!

#

Welcome @stiff oak!

#

Welcome @keen apex!

abstract pebble
#

Also, is it possible to run several actions in parallel? I.e. build a cough DAG?

autumn swallowBOT
#

Welcome @stuck basalt!

#

Welcome @sly wasp!

#

Welcome @cobalt crater!

#

Welcome @tough mesa!

wispy tapir
wispy tapir
autumn swallowBOT
#

Welcome @slim elbow!

autumn swallowBOT
#

Welcome @digital hinge!

#

Welcome @thorny violet!

#

Welcome @alpine valley!

#

Welcome @lean imp!

#

Welcome @runic cloak!

#

Welcome @rough sierra!

#

Welcome @nocturne quest!

#

Welcome @waxen void!

#

Welcome @coarse sorrel!

autumn swallowBOT
#

Welcome @nocturne moth!

#

Welcome @swift barn!

#

Welcome @supple blaze!

#

Welcome @swift barn!

#

Welcome @civic quartz!

#

Welcome @stoic sentinel!

#

Welcome @drowsy lotus!

#

Welcome @grim oriole!

autumn swallowBOT
#

Welcome @serene charm!

#

Welcome @ripe hornet!

abstract pebble
wispy tapir
rain oriole
rain oriole
abstract pebble
autumn swallowBOT
#

Welcome @neat cipher!

#

Welcome @lost moon!

abstract pebble
#

Something like this:

on: workflow_dispatch
jobs:
  one:
    runs-on: ubuntu-latest
    steps:
    - run: dagger do one
  two_a:
    needs: one
    runs-on: ubuntu-latest
    steps:
    - run: dagger do two_a
  two_b:
    needs: one
    runs-on: ubuntu-latest
    steps:
    - run: dagger do two_b
  three:
    needs: [two_a, two_b]
    runs-on: ubuntu-latest
    steps:
    - run: dagger do three
rain oriole
#

I believe Buildkit supports distributed workers, it's just how that integrates with GH Actions

rain oriole
autumn swallowBOT
#

Welcome @tender goblet!

#

Welcome @reef crown!

#

Welcome @slate summit!

#

Welcome @steep pond!

#

Welcome @crisp cypress!

#

Welcome @lime niche!

#

Welcome @neat crane!

#

Welcome @swift barn!

#

Welcome @dense vapor!

#

Welcome @river imp!

#

Welcome @sonic reef!

jaunty thorn
#

Congrats on the launch yall!

#

Now I can finally easily pester my team with links without making them sign up first lul

autumn swallowBOT
#

Welcome @swift barn!

#

Welcome @bold cliff!

#

Welcome @normal adder!

#

Welcome @unreal parrot!

#

Welcome @jade mist!

#

Welcome @untold ravine!

#

Welcome @misty sail!

#

Welcome @fair igloo!

winter linden
#

Welcome everyone! FYI I just disabled automated welcome messages, now that we're public and more people are joining, it's a bit overwhelming 😅 But you are still just as welcome!

autumn swallowBOT
#

Welcome @sand lotus!

#

Welcome @rich mauve!

winter linden
#

OK, I don't think that worked @wispy tapir 😉

autumn swallowBOT
#

Welcome @wanton yew!

winter linden
#

Actually that setting was for a different feature @wispy tapir , we need to turn off "DaggerBot". Help @cloud canyon

#

We have a bot rebellion on our hands

wispy tapir
#

Ahhhh it comme from @autumn swallow 😮

autumn swallowBOT
#

Welcome @tall iron!

wispy tapir
#

So yes, you must update the configuration from that bot, my bad

autumn swallowBOT
#

Welcome @distant flint!

#

Welcome @rocky mortar!

winter linden
#

OK I think I found it

wanton yew
#

I just opened Docker desktop to work through the QuickStart, one of my old containers is ‘trusting_solomon’, seems fitting today.

winter linden
winter linden
wanton yew
winter linden
wild bluff
#

Hey all, I'm trying to figure out how to clone a Git repo into an ephemeral directory in Dagger and I'm having a hell of a time. Can anyone point me in the right direction or show an example? Thanks!

winter linden
# 
$ cat example.cue
package main

import (
  "dagger.io/dagger"
  "universe.dagger.io/git"
)

dagger.#Plan & {
  actions: pull: git.#Pull & {
    remote: "https://github.com/dagger/dagger"
    ref: "main"
  }
  client: filesystem: "./result-of-git-clone": write: contents: actions.pull.output
}

$ dagger do pull
$ ls ./result-of-git-clone
#

(which in the case of git, is actually a wrapper to the core action core.#GitPull, since Dagger has native support for git)

wild bluff
#

And I can probably pick out specific files from the Git directory via fs.#Copy?

winter linden
#

Yes #Copy or #Readfile depending on what you need

wild bluff
#

👍 Thanks. Any chance there's an LSP for Cue that I can plug into Vim? Not having syntax highlighting is killing me

winter linden
#

I believe there is

#

We should add a docs page listing them 🙂

wild bluff
#

Ah, filetype plugin but no LSP. Still helps though.

winter linden
#

Would you mind opening an issue describing what woukd be the ideal vim setup for you? That would be very helpful!

wild bluff
#

Will do when I get a better internet connection. Currently on a plane

#

Hrm, having trouble wrapping my head around how fs.#Copy would work in this scenario

#

I'm passing the output of my git.#Pull step to the input of fs.#Copy.

#

I'm expecting to be able to supply a list of strings of files to pull out

winter linden
#

what’s the full import path of that fs package?

winter linden
winter linden
#

Currently core.#ReadFile only supporte one file at the time, but we can create a new action that reads several, as you described. In fact you can create one yourself in CUE by wrappin multiple #ReadFiles in a for loop

turbid tulip
#

It’s also possible that #Merge could be useful for this, if you’re wanting a file system state.

haughty heron
#

Hi all! I am curious, what is "the stage" channel?

mystic mantle
#

But for now, there is nothing on it anymore

#

The Stage can hosts more people, but without video

haughty heron
#

Thanks @mystic mantle

wild bluff
#

@winter linden I think I explained things poorly. I'm trying to basically copy 2 files from a remote repo into the current working directory, then throw the remote repo away.

winter linden
winter linden
#

Here you go @wild bluff 🙂

package main

import (
        "dagger.io/dagger"
        "dagger.io/dagger/core"

        "universe.dagger.io/git"
)

// Pick certain files from a remote git repository
#GitPick: {
        remote: string
        ref: string
        pick: [...string]

        output: dagger.#FS & _copy.output

        _fetch: git.#Pull & {
                "remote": remote
                "ref": ref
        }

        _copy: core.#Copy & {
                input: dagger.#Scratch
                contents: _fetch.output
                include: pick
        }
}


dagger.#Plan & {
        actions: pick: #GitPick & {
                remote: "https://github.com/dagger/dagger"
                ref: "main"
                pick: ["README.md"]
        }

        client: filesystem: "./output": write: contents: actions.pick.output
}
winter linden
tranquil timber
#

can someone ELI5, I am having a hard time understanding how dagger compares to something like the dsl's of jenkins and stuff. ive read the docs a few times and I get how cuelang is useful for data transfers but Im lost on how it fits the CI use-case well

winter linden
tranquil timber
#

okay I think that makes sense to me

winter linden
#

So it doesn’t replace jenkins (it’s not a CI runner) but it can do a lot of the things your CI runner can do, only better and more portable. So over time your CI configuration shrinks, until it’s just “run dagger”

tranquil timber
#

thank you, i guess the follow-up would be what do you see the pitfalls of the makefile method that is addressed by dagger?

winter linden
#

Jenkins, Github Actions etc. have this primitive concept of atomic actions/steps on the one hand, and high-level workflows/pipelines on the other. In Dagger there is only actions: an action can be made of other actions, etc as deep as you need. So Dagger actions are Github Workflow and Action rolled into one. That composition model is the real superpower of Dagger.

winter linden
#

The most powerful aspect of Make of course is that it’s a declarative DAG layout + an imperative script for individual actions. That remains the best model for supply chain problems

tardy storm
winter linden
#

Same thing that made Docker stand out from Openstack, even after they added support for containers

#

Some things you can’t bolt on

#

(I mean there are other things too but I’n watching a 3yo and 1yo so went from the most concise answer 😁

tardy storm
tardy storm
bold crater
#

Speaking of kids, my 4 yo asked me to speak to his preschool class about what is a software engineer. What should I say? What kind of swag should I leave with them.

knotty wren
#

Hello,
I started integrating Dagger with Kraken CI.
And I encountered the first issue: how to disable coloring logs from Dagger?

tall current
#

Hey, anyone tried setting up dagger for a project which has more than one dependency for running tests. Like setting up database, cache and queue etc?

shut shore
sour valley
swift inlet
swift inlet
swift inlet
winter linden
shut shore
#

Cool, thanks for the answer guys! Yeah, I guess for now I can use Dagger to wrap Docker Compose for now, but it would be cool to be able to handle it all just with Dagger, to reduce the number of moving parts.

knotty wren
winter linden
#

Thank you!

winter linden
knotty wren
#

Why dagger is not built by dagger but by Makefile?

winter linden
knotty wren
#

Nice 🙂

winter linden
wild bluff
#

Is there a way to take CLI input from the user?

winter linden
proud vessel
#

Hey All,Any plans to include Azure devops in CI environment

minor pewter
#

Hi, i'm new to dagger and pretty interested in it. I have several questions: (1) Do I need to write a CUE file from scratch to build CI pipeline? Are there any example projects and docs for those popular programming language or frameworks: Go/Python/Java/JavaScript/... ? (2) What is counterpart component of Dagger, like GitHub Actions, CircleCI orbs ?

sour valley
# minor pewter Hi, i'm new to dagger and pretty interested in it. I have several questions: (1)...

there is an example for github actions on how to integrate a dagger do into a pipeline. the pipeline will be similar for others too https://docs.dagger.io/1201/ci-environment
the documentation is currently a work in progress from what I can tell 😉

you can find a few examples here: https://github.com/dagger/dagger/tree/main/pkg/universe.dagger.io/examples

and I am currently working on a python app and trying to use dagger for testing and packaging it (pytest, docker build and helm chart publishing). the cue file isnt done yet though and I am still learning too 😉
https://github.com/sebastianhutter/mikrotik-dns-operator/blob/main/mikrotik-dns-operator.cue

minor pewter
bright spire
proud vessel
#

@bright spire Thanks Much!

fallen ocean
#

Is there a public roadmap for Dagger? I am poking around Github but didn't find one yet.

turbid tulip
keen holly
turbid tulip
winter linden
keen holly
# winter linden What part do you find “steepest”?

Honestly I find it really really hard to get started when I try to use Cue since their docs feel like they're just missing better usage examples. So to me, I think it's more that jsonnet is quite simple to get started using their docs, and with Cue i'm like searching all over their docs and examples and struggling to get a grasp on it overall.

#

I'd say, Cue itself isn't terribly hard to learn, but their docs are just not that amazing when your getting started

winter linden
#

@keen holly we've had that experience too... there is a "what is CUE?" on the dagger docs btw 🙂

tulip rune
#

cuetorials is good

fallen ocean
#

😄

unkempt wigeon
#

I found "the logic of cue" a good starter, just to get behind the ideas of CUE
https://cuelang.org/docs/concepts/logic/

after that, I agree, the CUE documentation is not the most consistent source to learn.

CUE
The Logic of CUE

Learn about CUE's theoretical basis and what makes it different.

granite sand
#

Hey everybody 👋

winter linden
#

I am running my first dagger action in a Github Codespace 🙂 So far so good

#

I also tried on gitpod, but something is causing the buildkit commands to hang

slender star
latent vapor
#

This is what I mean by sort of seems to work. I'm not sure why the commandconn errors are present.

WARN[0007] commandConn.CloseWrite: commandconn: failed to wait: signal: terminated 
WARN[0007] commandConn.CloseRead: commandconn: failed to wait: signal: terminated 
WARN[0007] commandConn.CloseWrite: commandconn: failed to wait: signal: terminated 
[✔] actions.build.container              10.2s
[✔] client.filesystem."./".read          0.6s
[✔] actions.build.container.export       0.2s             ```
winter linden
#

Didn’t know you were at Gitpod now 🙂

latent vapor
#

Since Nov'ish.

granite sand
#

Hey again. So I was playing over the weekend with some IaC things and ended up creating a Hetzner Cloud instance (comparable to a DO droplet or Linode node) with terraform and configure it with ansible playbook.
this approach already made me kind of crazy and started to become a mess pretty quickly.

is dagger a tool that combines those tasks? (resource managment and configuration of instances)

#

and good morning from my timezone! 🙂

minor pewter
#

Hi, what editor and plugins do you use for write CUE file ? I found that VSCode is not very powerful for this

#

syntax highlighting, parenthesis autocomplete, etc

winter linden
winter linden
#

I kind of want an action that takes another dagger action as input, and produces the Github Actions or Jenkins configuration to run it 😁

granite sand
#

yeah ok, that sounds interesting

#

Hetzner Cloud has a python client or an API in general. How would I start to integrate this? The "docker philosophy" to reach idempotency with just "building it again" is actually a way better approach compared to Ansible IMHO - so, yeah, there might be more easy and better maintainable ways to implement this...

winter linden
wind violet
#

👋 Hello, I am new to dagger and tried the examples which worked. Is there an example to use aws sam?

swift inlet
wind violet
#

Is there a How To to create Dagger packages?

swift inlet
wind violet
swift inlet
# wind violet Yes

I wanted to publish this doc today, you can start one, and we'll help you along the way, in 1:1if necessary 😇

swift inlet
rain oriole
swift inlet
rain oriole
#

Were you just going to port the existing doc?

swift inlet
wind violet
candid talon
#

Is there a ballpark time of day when releases are published? I'm getting ready to record a video about Dagger+Jenkins and saw yesterday that Tuesday is the typical release day and I want to hold off to try out 0.2.5.

rain oriole
candid talon
candid talon
rain oriole
turbid tulip
candid talon
#

I'm assuming alarms are going off since the Auto Release failed?

slender star
latent vapor
turbid tulip
slender star
#

@candid talon I was going to play with running Dagger in Jenkins as well. Super interested to see what you're working on!

heavy gazelle
#

0.2.5 is with @cloud canyon 👋🏻

cloud canyon
cloud canyon
#

@candid talon Pressing the button in 5

#

@candid talon Workflow running now ...

#

@candid talon And it's released 🙂

candid talon
rain oriole
cloud canyon
#

@rain oriole Nothing, just forgot ... merged now

winter linden
#

Hi @everyone, now that we have launched, we are switching our focus to incremental improvement. We need your help prioritizing the most important bugs to fix, features to implement, and documentation to write. If you've tried Dagger and have feedback on how we can improve the developer experience, comment and upvote here! https://github.com/dagger/dagger/discussions/2052

GitHub
How can we improve the developer experience? · Discussion #2052 · d...

Hello developers! Now that we have launched, we are turning our attention to incremental improvement. There are many bugs to fix, features to implement, and documentation to write. We want to prior...

shrewd jolt
#

haha 100000% cryptic error messages from cue, man, we'd use cue for so much more if the getting real error context didn't require evaling and greping for incomplete, haha

#

that's probably a better discussion for the cue slack, though, not here

winter linden
#

Well, cue's problems are also our problems now 😉

hasty yarrow
#

When I was trying to write a plan, it was a lot of trial and error. How does one learn to write plan files? Is that something for the Github discussions?

winter linden
#

I think a lot of people encountered the exact same issue @hasty yarrow

paper shore
hasty yarrow
#

Certainly that is helpful, but it won't help you with concepts like stages having inputs and outputs, and those inputs determining the ordering of your jobs

cloud canyon
jaunty thorn
sacred kestrel
stable tartan
faint sleet
#

Hi, if your trying to use dagger to deploy to a server, in dagger terms, is the server a "client" or am I missing something? I'm really new to dagger, and am struggling getting my head around the docs

paper shore
faint sleet
#

So, do I need dagger running on my server (that I want to deploy to) and my laptop where I want to start the deployment off from?

winter linden
faint sleet
#

I have a basic deployment to start with, but then I'd like to migrate us from Azure Pipelines to Dagger, but I need to get my head around it all first

faint sleet
#

So, I suppose one of the first things that I need to do, is to install buildkit on my server?

#

If I already have docker.io installed on my Ubuntu 20.04 server, do I still need to install buildkit?

swift inlet
#

Not install, but we run Buildkit in a container. So you'll have to run this docker container

#

So you'll just have to run the Buildkit container there

faint sleet
#

Can someone point me in the direction of a docker-compose file that I can use to run a Buildkit container please?

swift inlet
torpid linden
faint sleet
#

Wow, the support here is amazing!

faint sleet
swift inlet
swift inlet
torpid linden
#

Will do, sure.

faint sleet
swift inlet
faint sleet
swift inlet
swift inlet
faint sleet
swift inlet
swift inlet
faint sleet
paper shore
faint sleet
#

So, I'm still going to need an "action" on the server side, to actually pull down the git repos? Or will the client (my laptop) have an action to tell the server to download the git repos? Sorry, I'm getting confused 😦

paper shore
#

Dagger doesn't handle your build orchestration, so something's gotta tell it when, where, and what to build. Typically this is done in a system like Github Actions or Gitlab CI (or Jenkins or CircleCI or ADO or Concourse or any of a bunch of competitors -- this is a rich space :D).

You could certainly do something different, but if I were setting up CI for a Go app like BoxWallet that appears to be client-only (do you have a backend for BoxWallet? I don't understand the crypto space as well as I perhaps should), I'd make a plan with a handful of actions. Perhaps:

  1. Build
  2. Package (to .tar.gz)

Then write a Pipeline in Gitlab CI that runs dagger do build on all commits to any branch and dagger do build package on commits to master. On tags, additionally have Gitlab CI create a Release from the build artifacts that come out of dagger do package.

faint sleet
#

Sorry, my BoxWallet username, isn't helping here, as it's nothing to do with BoxWallet in this case. So, I have two things that I'm trying to achieve, one is for me personally, and the other is much bigger, for work. For me personally, all I need is for me to be able to run dagger do something (on my laptop) and then it instructs the Dagger running on my server, to pull the latest changes from master, then build with Go, then restart the Go binary, so that it's running the latest version.

#

My work stuff is more complicated, so I'll work that out when I've got my (more simple?) personal project working. 🙂

#

I hope that makes sense, and thank you for your time, you're being really helpful 🙂

paper shore
#

It's also kind of an old-school approach, using your server as your build machine. Modern CI/CD processes would rather see the thing you run on your laptop to be a git push, have some build processes hooked up to your source control, and handle deployment of the build artifact from there.

faint sleet
#

At work, we have a separate build server that builds out docker images, so I can see Dagger being more used there, I'm just trying to learn the basics on my per project first 🙂

paper shore
#

Certainly if you can ssh to your server, Dagger could do so as well and run arbitrary code there 🙂

faint sleet
swift inlet
faint sleet
#

I guess, another question I have, is how I have Buildkit and up and running on my server to "listen" to the commands from my laptop?

swift inlet
#

No problem 😇 , so dagger is just a CLI, a client that understand your local Cue and translates it to a language that Buildkit understand. Once it is translated, the CLI communicates with its server, the buildkit daemon for the execution part. We don't mind where the server is. Whenever running a command, and without setting the env var specifying that you already have a remote buildkit running, we will spawn a buildkit on your local machine. We do that for convenience

faint sleet
#

So, is there a simple "plan" that I can create and run, on my server, that would simply make sure that Buildkit was downloaded and running currectly, and listening for my client (laptop) commands?

swift inlet
#

Totally yes 😇
(Btw, thanks for all your questions, it will be a nice doc add-on)
In order to do that, you'll have to do 2 things:

  1. Run this command on your server: docker run --net=host -d --restart always --name dagger-buildkitd --privileged moby/buildkit:v0.10.0
  2. I'm looking for it 😇 still searching 🤣
swift inlet
#

So, 1 will spawn your buildkit container, the second will connect your docker daemon to the remote one (your server one).

#

From that moment, the Dagger CLI will be connected to your remote docker client (thus remote buildkit container)

#

It will be a good PoC

#

If you want, we could 1:1 @faint sleet if you feel you're still missing something or that my explanations are not clear enough 😇

faint sleet
#

Your explanations are brilliant, I just need to up my knowledge. I'd love to start a 1:1 with you and accept your invitation 🙂

mystic mantle
mystic mantle
#

So I didn't really need a dagger running on my server, just SSH and a Docker engine running, I guess docker-compose binaries as well.

paper shore
mystic mantle
#

We had it in 0.1 if I remember right. And yes, this is a very composable system that would fit perfectly in 0.2 I think

faint sleet
#

@swift inlet thank you so much for your time 🙂 It was really valuable 🙂

rain oriole
mystic mantle
rain oriole
ocean anchor
#

Hey, I'm curious if anbody here has created a CI/CD pipline for a Bazel monorepo using Dagger? If so, I'm curious how it went!

mystic mantle
#

I would be very interested to see how we can integrated with bazel as well, we're not there yet. It's not really a CI per se, but I don't know if it could be added in this thread: https://github.com/dagger/dagger/discussions/1677

GitHub
Which CI environment integration should we cover next? · Discussion...

We started writing a new doc page - From local dev to CI environment #1678 - and would like to know which CI/CD platform you would find most useful for us to document next. Since everyone that is u...

ocean anchor
#

I'm also curious how deep these CI/CD platform integration might potentially go? E.g. if I declare my CI pipeline in dagger and it has a bunch of parallel steps, might Dagger run each parallel step on different workers if the underlying CI platform allows it? Or is that out of scope for Dagger?

mystic mantle
#

But this buildkit cluster needs to be contactable from the CI env, I guess.

ocean anchor
#

Yeah, so I guess it depends on if the CI platform decides to create a native Dagger integration?

mystic mantle
#

We're talking about that in the #dev-audio if you want to join :p

#

but the idea is : No, not necessarily. You could have a CI that can access a remote buildkit cluster that you host however you want. In your CI, at the dagger step, you need to setup a env var : BUILDKIT_HOST and point to the host of your buildkit cluster

vocal lotus
mystic mantle
#

lol, I'm clearly a discord noob

vocal lotus
#

That's kinda hidden stuff

mystic mantle
#

#<dev-audio>

vocal lotus
#

you need the id, so you need dev options enabled and a right click on the channel

mystic mantle
#

ohhh ok

#

i get it

vocal lotus
mystic mantle
vocal lotus
#

yay

mystic mantle
#

Thanks @vocal lotus

vocal lotus
#

no problem

faint sleet
#

Hi, was going to ask if the dev-audio's happen each day?

swift inlet
faint sleet
#

Nice, ok, I'm still kicking the tyres at the moment, so I don't have many useful questions, just newbie ones 🙂

#

Is it best to start with dagger project init for a new client project?

#

And would you do that inside your repository, so that it all get's added?

#

and, does dagger project init create a default "plan"?

faint sleet
#

and, what would be a suggested name and location for the cue file that contains the "plan"?

mystic mantle
mystic mantle
mystic mantle
mystic mantle
faint sleet
mystic mantle
#

yep

faint sleet
#

That's really kind of you, but I don't want to waste any of your time. I'm literally coding it as I get answers for my questions 🙂

mystic mantle
#

Well, I'm here to help

faint sleet
#

I'll join in a minute, I'm just working on our production system 🙂

analog iron
#

-an 😄

#

👋

#

just here to listen to the soothing voice of Tanguy

loud glade
#

(had to leave, I have 2 "demo" call on my own to do now 😓 )

winter linden
#

FYI @turbid tulip and I are reviewing a very cool feature he's working on. If anyone wants to follow the stream on #dev-audio 🙂

quartz lodge
#

Neat!

vagrant tiger
#

Hey all. I'm trying to figure out how to contextualize dagger. I have this notion of an intent based pipeline (https://github.com/cdfoundation/sig-interoperability/discussions/91) wherein we say "build things kinda like this, then deploy kinda like this", but leave the specifics up to the backing implementation. Is that conceptually what dagger does in y'all's opinion?

GitHub
Intent-based pipelines · Discussion #91 · cdfoundation/sig-interope...

Hey all. I'd really like a system that allows me to specify a subset of information than vendors typically require to setup, validate and deploy code. Ideally, this would be a yaml-based DS...

winter linden
#

@vagrant tiger Dagger gives you a platform to create your own "intent-based" DSL, and expose it to end users.

#

Then in the backend expand it into a precise implementation, and run it

#

So we don't define such a DSL, or attempt to standardize it, but give each team the tools to create their own. Something that many are trying to do already, but at great engineering cost

vagrant tiger
#

Do you have a repository with an example that a developer might write and what it turns into on the other side?

clear raven
#

Since people were wishing for an Azure Devops implementation, https://github.com/joachim-isaksson/dagger-for-azure-devops seems to be working now after realizing rmdirSync doesn't exist on Node 10 that devops uses (oops) It's rather heavily based on the github action implementation and I published an internal package to my devops and the build/cleanup runs fine.

Since I'm just testing dagger for possible later use, I probably should not be publishing and maintain the package. Anyone interested is welcome to just copy the code and run with it, otherwise it may at least inspire someone when getting started writing a possibly more full featured implementation.

GitHub
GitHub - joachim-isaksson/dagger-for-azure-devops

Contribute to joachim-isaksson/dagger-for-azure-devops development by creating an account on GitHub.

#

...and now off to work.

winter linden
clear raven
#

Maybe I should add after quickly testing, it runs on ubuntu-latest build machines, something about a manifest fails if using windows-latest, guessing it pulls the linux image into a windows docker or something. Not quite sure what the behavior should be when run on a windows machine since I don't have one to test on locally atm. But may look at it later this week.

swift barn
#

Hi guys, i'm having trouble with multi-repo project.

How do you guys advice on using dagger for multi-repo project. For example need to produce few artifacts in 3 different repo's and merge those artifacts together. Do i need a 4th repo just to let dagger combine the artifacts?

silk apex
lilac radish
candid talon
#

The video I did for Dagger + Jenkins just went live. I wanted to ask if it was ok to post a link to the YoutTube video before just posting it since I'm new to the community.

swift inlet
winter linden
silk apex
bright spire
#

I'm waiting from Microsoft to have a free pool agent for this open source project in order to have integrated build + tests under devops

#

And publish it on the market

silk apex
slender star
slender star
flat summit
#

Super pumped to be here! 🙂

#

Wonder how best to contribute, should I check out issues?

loud glade
#

👋 working on a "tekton" package for dagger… something like

package tekton

import (
    "dagger.io/dagger"

    "universe.dagger.io/x/vincent@sbr.pm/tekton"
)

dagger.#Plan & {
    actions: test: task: {
    // Test: inline task tekton.#Task
        inline: {
            task: tekton.#Task & {
                definition: contents: #"""
                apiVersion: tekton.dev/v1beta1
                kind: Task
                metadata:
                  name: git-clone
                spec:
                  steps:
                  - name: clone
                    image: gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.21.0
                    command: ["/ko-app/git-init"]
                    args: ["-url=https://github.com/vdemeester/buildkit-tekton", "-revision=main", "-path=/workspace/foo"]
                  - name: ls
                    image: bash:latest
                    command: ["ls", "-l"]
                    args: ["/", "/workspace", "/workspace/foo"]
                """#
            }
        }
    }
}

would rune the "git init" clone and then list the content.

11:40AM INF actions.test.task.inline.task._dag."0"._run._exec | #3 8.769 {"level":"info","ts":1649324452.0669842,"caller":"git/git.go:169","msg":"Successfully cloned https://github.com/vdemeester/buildkit-tekton @ a17d0023784720d746c679ade01ba3963d859e37 (grafted, HEAD, origin/main) in path /workspace/foo"}
11:40AM INF actions.test.task.inline.task._dag."0"._run._exec | #3 8.785 {"level":"info","ts":1649324452.0828714,"caller":"git/git.go:207","msg":"Successfully initialized and updated submodules in path /workspace/foo"}

(currenty in a very very wip branch in my fork)

#

(and it support tekton oci bundle as well as "inlined" definition)

cloud canyon
#

@loud glade That's awesome! Let me know if you need any help

winter linden
#

Hi all, we are working on adding contents to the documentation, here are two new pages, with more coming:

Dagger Actions | Dagger

Actions are the basic building block of the Dagger platform.

Core Actions Reference | Dagger

Core Actions are primitives implemented by the Dagger Engine itself. They can be combined into higher-level composite actions. Their definitions can be imported in the dagger.io/dagger/core package.

paper shore
winter linden
#

Yeah that was the case until yesterday... We might have to change the title then. The reality is... It actually all starts with an action 🙂

long moon
#

👋 hello everyone!

#

a newbie question, what is the supposed way to get the "output" of deployment, such as url from netlify? in last year version, dagger supported "query", i cannot find it in latest doc. thanks!

slender star
# long moon 👋 hello everyone!

👋 Welcome @long moon !

For now use something like dagger do deploy --log-format plain

There are issues for improving the DX around inputs and outputs as well. Coming soon!
https://github.com/dagger/dagger/issues/1351
https://github.com/dagger/dagger/issues/1806

GitHub
Europa: add outputs to screen · Issue #1351 · dagger/dagger

I find the pre-europa outputs very useful, just wish you could control which outputs to show. Europa is well positioned for this, maybe something like: engine.#Plan & { actions: { build: pu...

GitHub
[Feature] Missing `dagger input list` style feature in Europa · Iss...

In v0.1 , you can list all the fields that needs to input with type and description: $ dagger input list Name Type Description token string Token to access Github But in v0.2, you can not list the ...

long moon
sharp marsh
# long moon thanks for info. yes it will be great to pinpoint the outputs. look forward to i...

another thing that you can do is use the client:filesystem write capability to write the outputs into files in your client FS in case you need to do some automation without having to grep into the output of --log-format plain. In the case of netlify, the Dagger action is already exporting those values. You can check it out here: https://github.com/dagger/dagger/blob/main/pkg/universe.dagger.io/netlify/netlify.cue#L95-L99

GitHub
dagger/netlify.cue at main · dagger/dagger

A portable devkit for CI/CD pipelines. Contribute to dagger/dagger development by creating an account on GitHub.

rain oriole
#

What I'm doing in the meantime is what @sharp marsh just suggested.

import (
  "encoding/json"
  ...
)

dagger.#Plan & {
  client: filesystem: "output.json": write: contents: json.Marshal({
    url: actions.deploy.url,
    deployUrl: actions.deploy.deployUrl,
    logsUrl: actions.deploy.logsUrl,
  })

  actions: {
    deploy: { ... }
  }
}
#

You can also output in yaml, it's just json allows usage with jq. Or even a simple file with:

client: filesystem: "url.log": write: contents: actions.deploy.url
sharp marsh
rain oriole
verbal canopy
#

Is that planned to be more like logging or more like terraform structured outputs?

rain oriole
#

Not sure about terraform, but I think both, if I understand you.
Default can be a simple table with values at the end of run. But you can ask to output in json so you can pipe to jq.

verbal canopy
#

Terraform "outputs" are like reverse variables. Just a key mapped to the value of any given object path

winter linden
#

Straight from stdout? Or write to a json file first?

verbal canopy
#

But having a named output lets you change where the value comes from without affecting the "api".

long moon
rain oriole
#

Sure, but you'll need --log-format plain. It'll output to stderr next to the rest of the logs, but may be enough for you 🙂

long moon
#

got it. thanks🙏

faint sleet
#

Hi, just wanted to say a quick thank you for all of the support I got today 🙂

#

I thought it was about time I posted something, without actually asking a question

stuck wyvern
#

I absolutely love that dagger gives me control to do basically anything on my dockerfile wishlist, just sans dockerfile.

#

And no more temporarily copying things around with make.

faint sleet
#

Is there a way to build a docker image and transfer it directly to a server and run it there? Effectively, bypassing the need to upload it to a registry?

rain oriole
faint sleet
#

Wow, that's amazing!

winter linden
frail mulch
#

hi Dagger team!

#

new in here and in discord in general

#

but happy to be here

#

thanks @heavy gazelle for the invite!

winter linden
#

Welcome @frail mulch 🙂

frail mulch
#

@winter linden hi there!

#

I might be asking for some help..

#

I was discussing with @heavy gazelle on how to migrate some github actions to use dagger to build some projects

winter linden
#

Happy to help any time

frail mulch
#

@winter linden thanks!

faint sleet
#

Is it wrong that I'm waking up thinking of all the cool things I'm going to be able to do with Dagger? 😜

slender star
stoic knot
winter linden
#

Thanks @stoic knot ! It's really impressive stuff. I'm wondering if we could use it to orchestrate testing universe packages across multiple versions of dagger

narrow pebble
#

hello and good day to everyone. I want to ask a question, is it possible for me to use dagger to push docker image to GitLab container registry?

paper shore
lilac radish
narrow pebble
narrow pebble
desert stirrup
#

Hey guys - any tips or thoughts on working with cue in vscode? I would love an autocompletion/intellicode plugin

paper shore
desert stirrup
paper shore
desert stirrup
rain oriole
lilac thicket
#

Hah! I’ve only just discovered that dagger do foo bar baz, space separated:

  • runs my actions.foo.bar.baz action, but …
  • makes sure to run ONLY the prereqs for that action that are essential, through the DAG!

That is a fantastic feature 🙂

Are there Issues logged about:

  • making the nested/targeted action run more visible as a feature?
  • exposing that the comment closest to each actions. subkey is printed in the dagger do [--help] output
  • noting that dagger do foo bar baz --help shows the commands, and optional comment-based-description, of each of the sub-actions underneath actions.foo.bar.baz?

If not, I’ll file them! This is an absolutely killer feature 😁

winter linden
lilac thicket
echo palm
#

Hey~ were there any examples (pre Europa) for Kubernetes where the manifests were written in CUE? I have a vague memory of seeing something like that in Dagger-space...

winter linden
winter linden
echo palm
stoic knot
#

especially interesting as 3rd parties add to the universe & ecosystem

winter linden
#

We have a lot of inbound contributions to universe, so offering adequate testing infrastructure is important. It will help us keep a high quality bar.

paper shore
faint sleet
#

Is it possible to have a dagger project update happen automatically, after a dagger project init with the latter, also creating us a default dagger.cue file, with a dagger import in the top?

#

Also, we could perhaps have a small template, with comments, containing the different sections required?

#

I think this would be quite useful for new users, as I thinking that they would expect some kind of editable file after the init command?

paper shore
swift inlet
frail mulch
swift inlet
frail mulch
#

@swift inlet sorry for the delay

#

so basically it will be great to have the same steps but using dagger.. these examples will go in this book: http://mng.bz/jjKP so I want to make sure to show how dagger can help to run those actions also locally

rain oriole
#

fmtok8s-api-gateway

faint sleet
#

When naming actions, is there a good naming convention to follow? e.g. If you want to separate words? deploy-to-production or deploy_to_production or deployToProduction?

rain oriole
verbal canopy
rain oriole
sharp marsh
candid talon
slender star
# candid talon sorry for the non-response. I had an emergency come up right after I posted and ...

Np, @candid talon . Hope all's well. We put up an initial example with Jenkins (with much inspiration from you),
https://docs.dagger.io/1201/ci-environment
but I've learned that our best practice is to commit the cue.mod to git and thus avoid some dagger project init and dagger project update steps. So I'll be making another PR soon (to follow this one: https://github.com/dagger/dagger/pull/2102).

I'm setting up a Jenkins controller with dagger on it right now to play around with. Wondering about things like a shared buildkit cache across Jenkins agents, etc.

#

I already ran into issues with building dagger on the Jenkins image on M1 Mac (arm64) due to golang, so I'm building on my Windows machine (amd64).

candid talon
slender star
#

@candid talon did you use a Freestyle or a Pipeline project for your vids?

candid talon
#

pipeline. Freestyle is evil 👿

#

technically, It's a multibranch pipeline job

candid talon
cloud canyon
#

@candid talon @slender star re caching: there's a couple of options to go around:

  1. Export/Import cache from dagger: it supports the same --cache-to / --cache-from flags as buildx (e.g. export cache to a container registry)

  2. Or, lower level, looking at the doc shared by @candid talon, we could potentially start a buildkit daemon with a host volume to persist the cache

#

dagger already starts its own daemon with a persistent volume upon the first dagger do (a container named dagger-buildkitd with a dagger-buildkitd volume).

I don't know much about Jenkins, unsure what happens when you run a container, do they stay around with their volumes? If so caching should already work per-agent (not shared)

slender star
swift barn
#

Hi @everyone, just got to know about dagger dagger, pretty interesting project. I am a newbie learning DevOps and looking for some non-code contributions 🫂 that I could do with daggerdagger

rain gale
#

First contribution would to not ping the entire server lmao

native hinge
rain gale
#

They really need to fix the permissions KEKW

dense goblet
#

Maybe this should be disabled for default users

proper cloak
#

Yeh cheers 🤗

latent hatch
#

exactly lol

rain gale
#

Good morning though

hearty flame
#

Morning!

torpid linden
hearty flame
sinful dew
#

your admin should do his job and prevent this 😄

hearty flame
sinful dew
#

😄

winter linden
#

Sorry everyone, we will fix permissions to avoid this in the future.

Also: please don't be harsh on your fellow daggernaut who made this mistake, not everyone is a discord expert. It's really our fault for not putting a safety on this.

UPDATE: I have fixed the permission.

sharp umbra
#

🪙

sharp umbra
#

I run a GCP Discord server btw and what I've found helped was a channel where people read instructions, including netiquette. It even had a GIF on how to unselect the ping when you reply.

dense goblet
swift barn
#

I am really sorry for that disturbance. I don't really know how things work. This wont happen again. Sorry again 🙏

faint sleet
#

Hi, is it possible to get the ip address of a running container on a remote server, when running a plan from a client?

#

I hope I asked that correctly 🙂

rain oriole
faint sleet
faint sleet
verbal canopy
faint sleet
winter linden
#

@faint sleet note that Docker cannot guarantee that you can reach that IP address from your client machine. It can be a useful hack but important to realize it’s just that: a hack

faint sleet
faint sleet
#

If you wanted to perform a docker-compose up -d on a remote machine, could that be done via the universe.dagger.io/docker/cli or would it have to be done via SSH?

rain oriole
faint sleet
rain oriole
#

Yes. Just connected to a remote docker engine, just like the docker binary.

faint sleet
faint sleet
rain oriole
faint sleet
rain oriole
faint sleet
rain oriole
faint sleet
rain oriole
#

cli.#Run is a convenience that sets DOCKER_HOST for you. While you can issue any command (from docker.#Run, not bash.#Run, i.e., no script field), maybe that loses it's usefulness 🙂

faint sleet
#

I'm also presuming I can't have an ENV in this line:? flags: "-f": "${DEST_DIR}/docker-compose.dev.yml"

rain oriole
winter linden
faint sleet
paper shore
faint sleet
paper shore
faint sleet
faint sleet
# 
            command: {
                name: "docker-compose"
                flags: "-f": client.env.DEST_DIR + "/docker-compose.dev.yml"
                args: ["up", "-d"]
            }
#

For the flags: line?

paper shore
# faint sleet Does this look correct(ish)?

That should work, though I'd lean toward preferring interpolation to string addition. flags: "-f": "\(client.env.DEST_DIR)/docker-compose.dev.yml" reads better to me than the string concatenation you're doing.

They should be equivalent in practice, though.

faint sleet
echo palm
#

One of the projects I'm porting to Dagger uses ESLint in its CI, which throws the following error:

#21 148.0 ESLint: 7.4.0                                                      #21 148.0 ESLint couldn't find the config "react-app" to extend from. Please check that the name of the config is correct.                        
#21 148.0 The config "react-app" was referenced from the config file in "/src/cue.mod/pkg/universe.dagger.io/examples/todoapp/package.json".

Ignoring cue.mod/ isn't going to work for this project though as we also want to have Kubernetes manifests written in CUE that will rely on k8s definitions in cue.mod/gen. Any suggestions for the best way to work around this?

rigid epoch
#

Wondering something about Dagger's cache model: because of the way the registry is used as a shared cache between multiple machines, could I, in theory, distribute the work of a really large build across cloud execution nodes just by calling different dagger do targets on different nodes? Obviously you lose some of the simplicity if you do it this way, but if that's workable as an escape hatch in an extreme situation it'd definitely make me feel better about using Dagger on a really large project.

winter linden
#

We have work to do on packaging and productizing it, but the underlying tech (namely buildkit) supports it. You could rig such a setup yourself today.

rigid epoch
#

@winter linden that's great to hear! My team has an eng offsite/hackathon coming up, and I will probably do a Dagger POC for it. Really stoked.

distant heron
#

👍👍

thorny juniper
#

👋 Listened to the ShipIt podcast and got some ideas, some wanted to run them by here and see if any of my use cases would not be ideal for Dagger.

  1. We have CI bash scripts to automate a bunch of stuff, I basically wrote functions in bash and then execute them in GitLab CI, not very portable and now we plan to move to GitHub Actions. Was planning to eventually abstract them into a Go CLI program but Dagger seems like a good alternative for this? Yes/No?

  2. If I wanted to have abstracted and versioned scripts across all 100 repos (exaggeration) in my company, does that mean maintaining 100 cue files? I assume I can package this up and then have to update dependent versions in my 100 repos. We currently have this problem.

  3. We have a custom inhouse Go CLI tool that we use to abstract the build, deploy and other developer tooling like secrets. Could Dagger replace this or there would likely be a world where our custom CLI tool calls Dagger. We are turning this CLI tool into a API webservices to do all kinds of things from run trigger the build, deploy process. We currently writing our pipelines in Go and figuring out how to do all of this in Go. Dagger sounds like a better abstraction from modifying files, to doing a Git commit.
    The Golang webservice can abstract the CLI and HTTP but still run Dagger under the hood?

winter linden
thorny juniper
#
  1. We have a lot of one-off scripts for random stuff. Thinking of where we can write these and run them aside from bash. Dagger sounds like a place to put them especially if they form a DAG. I suppose I could also use it to run Terraform then take that output and apply it to a Kubernetes deployment.
winter linden
# thorny juniper What kind of pitfalls? I dont think it makes sense to give Dagger to all develop...

Absolutely, you shouldn't have to force every developer to learn CUE and the internals of Dagger. Whatever configuration format they already use (whether it's for an off-the-shelf tool, or your own DSL) they should be able to continue using that.

The pitfalls are in how you allow them to do that. Typical things to look out for:

  • If your tool generates cue files for Dagger to run, you're almost certainly wasting effort
  • If you don't have full interop with the entire Dagger ecosystem - for example if your plan cannot incorporate any Dagger action without some modifications specific to your tool - then you are fragmenting yourself out of the ecosystem and missing out on the value of Dagger's "lego" system

These pitfalls can be avoided, but in my experience, almost 100% of wrapper tools end up failing to do so.

Most of the times, it's better to:

  1. Write Dagger plans that load your developer's existing configuration files as inputs
  2. Give developers the dagger tool and show them how to use your plan with dagger do
  3. Let them continue to write the same files they're used to - no CUE or Dagger internal knowledge required

Your use case might be the exception, but again - I've seen many teams believe they were the exception, only to realize later that they had fallen in the pit 🙂

thorny juniper
# winter linden Absolutely, you shouldn't have to force every developer to learn CUE and the int...

Thanks, I'll think about this, I definitely dont think were an exception. Every company usually builds the same type of internal tool using whatever theyve got.
I'm thinking of using it to run DAGs that require centralized admin credentials. Maybe thats behind an API. It seems I can either use dagger in the background to run my logic instead of having to build those pipelines myself in a specific language or publish those APIs as a Dagger package and have each repo use them.

I'll experiment a bit and see what works.
Current usecase for a workflow might be:

  • Clone a GitHub Repo
  • Modify some files and submit a commit
  • Create an AWS ECR Repo
  • Push some ArgoCD configuration to a central GitOps repo.
stable mulch
#

Hi, I have a question. Do you have a plan to support to interactive actions (like workflow)? e.g. Manual approvals or plan-before-apply in dagger action.

rain oriole
stable mulch
soft kayak
#

hi folks! what is your take on the idea of either:
a) the user running a tool to covert cue to a pipeline provider format (e.g. github workflow)
b) having a cue file introspect itself (if possible) in order to generate and commit a pipeline provider formatted pipeline (e.g. github workflow)
is this crazy talk? contrary to the vision of dagger?
in case the goal was unclear, it is about having dagger as the source but benefiting from the features of the pipeline provider such as the visualisation of the DAG in github actions. At the moment, as far as I am aware, you can't represent the visualisation of the dagger DAG in the pipeline providers native visualisation. You have to manually wrap it as one step (and loose the visualisation) or wrap each individual action and relationship so it's visualised in the fullness of the DAG.

mystic mantle
#

Our priority would be more to give visualization into the Dagger DAG instead

soft kayak
#

got it. and, fair.

smoky shard
desert whale
#

hi there! would anyone have an example on dagger for a python project?

sharp marsh
# desert whale hi there! would anyone have an example on dagger for a python project?

Hey Gabriel! Coincidentally one of guides covers a basic python example. I think this is a good starting point to get introduced into Dagger https://docs.dagger.io/1205/container-images

Building container images | Dagger

You can use Dagger to build container images, either by executing a Dockerfile, or specifying the build steps natively in CUE. Which method to choose depends on the requirements of your project. You can mix and match builds from both methods in the same plan.

desert whale
sharp marsh
# smoky shard >Write Dagger plans that load your developer's existing configuration files as i...

Hey @smoky shard. For example, if developers are already used to writing Dockerfiles, you don't need to immediately go and tell them "now write Dagger actions". Instead, you can leverage on already existing actions (or create new ones) so you don't force them to switch. The idea about Dagger is to meet devs where they are. You have an example about the Dockerfile scenario I referred here: https://docs.dagger.io/1205/container-images

Building container images | Dagger

You can use Dagger to build container images, either by executing a Dockerfile, or specifying the build steps natively in CUE. Which method to choose depends on the requirements of your project. You can mix and match builds from both methods in the same plan.

smoky shard
slender star
#

Using what devs already have

bronze flame
#

Hi

rigid epoch
#

Does dagger have to perform some kind of search to locate usable cache layers on a remote registry? I'm trying to wrap my head around how this all works -- I've noticed that when building images with buildkit through docker, I have to specify which tags in the remote registry I want to consider as cache sources, but it seems like dagger doesn't do that.

#

I assumed that if it were possible to efficiently find cache across an entire registry, that would be the default behavior, and we wouldn't bother with --cache-from. But my impression of dagger is that it can treat the remote registry the way docker treats local cache -- searching through the entire thing to see if there's a layer anywhere that matches the current dockerfile and context

swift inlet
#

search usable cache

nocturne vector
#

hello, I can't open the page with documentation, it's ok?

mystic mantle
clever mesa
wraith niche
clever mesa
wraith niche
#

Are you involved in the cue packages spec?

clever mesa
# wraith niche Are you involved in the cue packages spec?

Nope. I implemented the tool https://github.com/octohelm/cuemod with go mod before the proposal for my custom usage. (hacks here: https://github.com/octohelm/cuemod/blob/main/pkg/modutil/util.go)

The proposal is from Paul
Here are some context https://github.com/cuelang/cue/discussions/730#discussioncomment-501147

It totally same as go mod but just rename go* => cue*.
Paul said it need to refactor codes for go mod to make it could reusable.

wraith niche
clever mesa
wraith niche
clever mesa
ionic plume
#

hi, what is the way to create custom package like universe.dagger.io and then use it on plan ? I have tested to create github repo with folders that contain package like universe.dagger.io, but I doesn't found the way to get it with dagger project update

rain oriole
#

There's a bit more details to it, we can help until the docs are available.

ionic plume
#

@rain oriole thx, it's work 😉

ionic plume
#

and there are a way to display output of bash.#Run even when is success on stdout ?

rain oriole
clever mesa
pliant fable
#

waveBOYE Hello Dagger folks! I am an engineer at GitHub and do a ton of DevOpsy things on the side. I found this project from a Medium post and I find this project fascinating. I personally have found myself in YAML hell many times before writing GitLab CI/CD pipelines and even GitHub Actions templates. I hope to use Dagger in my next personal project and learn more about it 🙂

slender star
grim sphinx
#

Hey, does someone has a java example?

wispy steppe
grim sphinx
#

Do you want to do something specific

ionic plume
#

hi, I have a plan with multiple actions that use the same input variable env. And this variable is provided by user with client.env (http_proxy, https_proxy, no_proxy). There are a way to pass client.env on each action without to recreate hash on each action ?

swift inlet
ionic plume
#

so the righ way is done by ?

dagger.#Plan & {
  client: {
    env: {
      http_proxy: string | dagger.#Secret
      https_proxy: string | dagger.#Secret
      no_proxy: string
    }
  }
  actions: {
    _env: {
      http_proxy: client.env.http_proxy
      https_proxy: client.env.https_proxy
      no_proxy: client.env.https_proxy
    }
    validate: helm.#Validate & {
      input: _installTools.output
      directory: client.filesystem."./".read.contents
      env: _env
    }
  }
}
#

where I pass env: _env on each block action

swift inlet
#

Can you please share your helm.#Validate definition ? It seems correct

ionic plume
swift inlet
#

It seems correct

tardy mauve
#

Is there a public roadmap available at all? For example, dagger is in beta, is that correct? If so, when are you looking to get to a 1.0 release etc.?

ionic plume
#

i need to replace

env: {
  env
}

by

"env": {
  env
}
#

now it's work fine, but I doesn't know why the really diffrence

orchid swallow
#

Is there some sort of catalogue of actions that not yet part of universe or core? If not, is it planned?

swift inlet
swift inlet
ionic plume
#

and to finish there are a way to append on string to generate cmd with multiple parameters ? Or maybee append on string list anf after convert to string. I doesn't yet found the right syntaxe to do that

slender star
# ionic plume and to finish there are a way to append on string to generate cmd with multiple ...

You can use + built-in or strings and list packages from CUElang 🙂
Example: https://cuelang.org/play/?id=4Mkj18ILvdN#cue@export@cue

References:
https://cuelang.org/docs/references/spec/#string-operators
https://pkg.go.dev/cuelang.org/go@v0.4.3/pkg/strings
https://pkg.go.dev/cuelang.org/go@v0.4.3/pkg/list

CUE
Language Specification

The CUE Language Specification Introduction This is a reference manual for the CUE data constraint language. CUE, pronounced cue or Q, is a general-purpose and strongly typed constraint-based language. It can be used for data templating, data validation, code generation, scripting, and many other applications involving structured data. The CUE t...

empty jay
#

Hi everyone, I just learned the existence of the dagger.io yesterday and found a super interesting tool. I was looking for something to get rid of our makefile hell. Great work 👏

eternal ocean
#

Hi! 👋 ,

I'm been digging through the docs and I'm wondering, what the thoughts are with packages & imports?

Currently from what I understand shared packages exist in dagger/pkg, running dagger project update (should) pull down what I need inside a dagger project from these packages.

Are there any thoughts to make it possible to be able to import from other git repos (like my thoughts are along the lines of if I had to provide a catalog of customisations, I'd like to be able to expose them as things teams could import) - for the meantime I guess I can check stuff into the cue.mod file in repos and share that between different repos that have the same actions

#

Another thing,

I've started/planning on solving some CI-y things I've come across in the past with Dagger and having playbooks for them to reference. Things like:

  • Templating a catalog of actions (hypothetically to provide to a team - relates to the question above)
  • Using the host OS to create docker containers for a web app / services to run e2e tests
  • Updating an infra as code repo post building an image (argo CD deployments)

Do we have a space where we share/showcase stuff like this? (maybe someones already done something similar 😄 )

winter linden
grave topaz
#

Hi all 👋 finally remembered to join the discord server! Having actively worked on GoCD 10 years ago (😱) and been among the very first Docker partners in Europe back in 2015 I'm really looking forward to seeing how two of my favourite "things" - CI/CD & containers - will progress together 👏

median mulch
#

Will there be a talk about dagger at KubeCon EU?

faint sleet
#

Hi, can anyone share any code on how to push an image up into an Azure repository please?

swift inlet
#

push azure

weary niche
#

Hey guys, I'm currently preparing a lightning talk to present to the messagebird engineering department (for a weekly friday talk session we have). I have an idea of what I want to quickly demo (docker image build + maybe helm chart deploy) but I would love a bit of help from the dagger team/community, especially on the CUE front, to make sure I explain CUE and dagger correctly

faint sleet
#

Does Dagger support "DockerSlim" for making images smaller?

wispy tapir
wispy tapir
weary niche
faint sleet
#

Is it possible to, in the client: filesystem: to read a directory above where the dagger.cue file is, or must the files be in the same directory or in sub folders?

rain oriole
faint sleet
# rain oriole You should be able yes, but relative paths are in relation to where you run the...

I see, so I've got 3x docker-compose files in one directory, and then sub folders for "dev", "staging" and "prod". I was going to have a generic dagger.cue file, in the parent folder, and then issue command such as dagger do devDeploy or dagger do stagingDeploy, but my plan is getting messy because of the size of it, so I decided to have 3x dagger.cue files, each in the separate folders, to keep it simpler, but I need to include the docker-compose file, for the environment of choice, by specifying the folder above? (if that makes sense)?

mystic mantle
#

you can do dagger do -p ./dev devDeploy from the root of your repo

#

since they are different cue files, I guess you could even do dagger do -p ./dev deploy, I don't believe the actions of each environments should clash on their names since they would be separated

#

(let me check that)

faint sleet
#

What's the best way of separating actions, so that they are independent?

rain oriole
faint sleet
faint sleet
mystic mantle
#

if the .input of the action n depends on the .output of the n-1

#

otherwise you need to create artificial dependencies with some env var. I think this hack is used in particubes while we add this explicit dependency feature.

faint sleet
mystic mantle
#

(the .input is the base image/container FS that this current container will run on.
The .output is the base FS with all the modifications that happened during the container execution)

faint sleet
#

Thank you

ionic plume
#

hi, there are a way to check if ninput image is not provided, to use default

#

in the following spirit, it not working:

// The docker image to use
  input: docker.#Image | *null

  if input == null {
    _defaultImage: #InstallTools & {
      "env": env
    }
    input: _defaultImage.output
  }
swift inlet
#

Default img