Need help migrating to dagger 0.2?

[shykes]

We are getting ready to release dagger 0.2, codename Europa. This release has one focus: improve the developer experience. It features a redesigned CLI and powerful new APIs. The result is a completely new way to develop CI/CD pipelines: more productive, more portable… and way more fun!

However, there is a downside: unfortunately, this release is not backwards compatible: plans written for dagger 0.1 will not run on version 0.2. Automatic migration is not supported, but manual migration is relatively straightforward. If you need help migrating your plan, we will be happy to assist you! Simply reply to this thread with a description of your configuration. If you've already started migrating, please let us know and share details of your progress and issues you're encountering. We will do our best to assist you!

Since we are a small team, we cannot promise to migrate all of your configurations on our own. But we will do our very best to help you get there. We are making this work our priority.

We apologize once again for breaking compatibility. We hope you will find that the new features of Europa are worth it 😁

[lyzhang1999]

We are working on migrating to dagger 0.2, but docker.#Run has some problem: #1466, I can only use dagger.#Exec for this time.

[helderco]

If you're replacing with core.#Exec then you must have a different issue. The one you pointed to is about having nested docker.#Builds. If you do have a nesting depth of 3 (docker.#Build inside a docker.#Build), you can unblock by replacing it with explicit fields:

-build: docker.#Build & {
-    steps: [
-        docker.#Pull & { ... },
-        docker.#Run & { ... },
-    }
-}
+build: {
+    pull: docker.#Pull & { ... }
+    run: docker.#Run & { input: pull.output, .... }
+    output: run.output
+}

These are functionally equivalent, docker.#Build is just a convenience to hook inputs to the previous output for you.

If this doesn't help you, can you share more details about your setup?

[lyzhang1999]

this would help me solved this problem, I just though concat the context manually is not elegant enough. in 0.1 API I use op.exec, It's perfect.

[shykes]

@ravilach wrote a whole Kubernetes deployment tutorial based on Dagger 0.1: https://shipa.io/miscellaneous/kubernetes-dagger-deployment-with-shipa/

Let's help him port that configuration to 0.2 !

See also: https://twitter.com/ravilach/status/1509579332758482947

cc @grouville

[ravilach]

Howdy Dagger Buds! I took the example straight from the Dagger v0.1 docs. I had a little trouble trying to figure out how to apply some Kubernetes manifest in the latest and greatest. The v0.1 docs were a great help [and hidden in the blog, I use EKS so had to wire in the AWS client]. Excited to see where the project goes :-)

[jpadams]

@ravilach I'd love to help update this to latest Dagger :)

[grouville]

@Guikingone tried yesterday to implement the Symfony demo package with dagger 0.2. The result is here, and is still too verbose (due to lack of documentation): thread twitter ici

Here is the actual implementation

There seems to be room for improvement, let's try to help him. What format would you prefer @Guikingone. We could totally do a live coding session on the Discord, it may help capturing the missing parts of the doc 😇

@helderco, @gerhard told you've used Symfony a lot. This might interest you

[helderco]

It's just to reduce duplication. See that in the next actions I'm using #Run instead of docker.#Run to reuse the input and _vendorMount.

[Guikingone]

Oh, that's nice, can we see this as a boilerplate for following steps? Maybe like a contract for each call?

Here's the "prettier" structure:

package symfony_demo

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

dagger.#Plan & {
	_vendorMount: "/srv/app/vendor": {
		dest: "/srv/app/vendor",
		type: "cache",
		contents: id: "vendor-cache"
	}
	_phpunitMount: "/srv/app/bin/.phpunit": {
		dest: "/srv/app/bin/.phpunit",
		type: "cache",
		contents: id: "phpunit-cache"
	}

	client: {
		filesystem: {
			"./": read: {
				contents: dagger.#FS,
				exclude: [".github", ".editorconfig", "CONTRIBUTING.md", "README.md", "vendor", "symfony.cue"]
			}
		}
		env: {
			APP_ENV: string
		}
	}

	actions: {
		build: docker.#Build & {
			#Run: docker.#Run & {
				command: name: "composer"
			}
			steps: [
				docker.#Dockerfile & {
					source: client.filesystem."./".read.contents
					dockerfile: path: "./.cloud/docker/php/Dockerfile"
				},
				#Run & {
					command: args: ["install"]
					mounts: _vendorMount
				},
				#Run & {
					command: args: ["dump-autoload", "--optimize", "--classmap-authoritative"]
				},
			]
		}
		#Run: docker.#Run & {
			input: build.output
			mounts: _vendorMount
		}
		tests: #Run & {
			command: name: "bin/phpunit"
			mounts: {
				_vendorMount
				_phpunitMount
			}
		}
		linting: {
			[string]: #Run & {
				command: name: "bin/console"
			}
			yaml: command: args: ["lint:yaml", "config", "--parse-tags"]
			xlif: command: args: ["lint:xliff", "translations"]
			container: command: args: ["lint:container", "--no-debug"]
			twig: command: args: ["lint:twig", "templates", "--env=prod"]
		}
		phpstan: #Run & {
			command: {
				name: "vendor/bin/phpstan"
				args: ["analyse"]
			}
		}
	}
}

Way better than the first one 😅

[helderco]

Oh, that's nice, can we see this as a boilerplate for following steps? Maybe like a contract for each call?

But that's what I did 🙂

[Guikingone]

Yes, I know, I mean, now I understand the goal of the directive, that was the question 😅

BTW, a huge thank you to both of you for the support, I can now explore Dragger with a better starting point, I have other questions about the Docker building phase (especially on how to copy executable from external image) but I'll see if I can solve them before asking for help in the discussions 🙂

Again, a huge thank you for the help 😊

[helderco]

Yes, I know, I mean, now I understand the goal of the directive, that was the question 😅

Oh, I see it now 😇

Sure, anytime 🙂

[grouville]

@Alvise88, If I recall, you had some configs pre-europa. Do you need help migrating ?

[munichbughunter]

I am interested in porting the serverless package.

[grouville]

Thanks @munichbughunter. For reference purposes, as we discussed privately, you're talking about this package: https://github.com/grouville/dagger-serverless, in which we tried to do an aws SAM like in Dagger. That would be an awesome contribution

[grouville]

@arnaud-soulie && @PaulBarrie, we talked privately on the fact that you were interested in porting your Ansible PR to post-europa. It's going to be so useful. Please keep us in touch: #1653

[PaulBarrie]

Hi @grouville, it is underway. I'm adapting the package to the new standards. I will be able to deliver a first sketch in the coming days :)