It's the start of a new year and to celebrate, we've been hard at work adding improvements to Dagger. Our latest release of the Dagger is v0.3.10, which incorporates two significant new features for status reporting and container metadata management.

### Dagger 0.3.10 Highlights

#### New Pipeline API

Dagger now provides a [Pipeline API](https://docs.dagger.io/api/reference/#query-pipeline), which enables developers and operators to programmatically group related operations together into "pipelines" for status reporting and visualization purposes (e.g. logs). This new feature makes it easier to cut through the "noise" of your CI's daily operations and improves visibility of specific operations or events.

Pipelines are hierarchical and can contain any number of child pipelines. Here's an example of using this new API in Go:

```go
// `c` belongs to the root pipeline at this point
c, _ := dagger.Connect(ctx)

// everything using `c` is nested under the `sdk` pipeline from now on
c = c.Pipeline("sdk")

nodejs :=
c.Pipeline("nodejs").Container().From("node:16").WithExec([]string{"yarn install"}) // pipeline is `sdk/nodejs`
lint := nodejs.Pipeline("lint").WithExec([]string{"yarn lint"}) // 
pipeline is `sdk/nodejs/lint`
test := nodejs.Pipeline("test").WithExec([]string{"yarn test"}) // 
pipeline is `sdk/nodejs/test`
```

#### Support for Container Metadata

Dagger now allows developers to add and manage container metadata via support for the [Dockerfile LABEL instruction](https://docs.docker.com/engine/reference/builder/#label). For any given container, you can now add a label (withLabel), remove a label (withoutLabel), print the value of a label (label) or print all the labels (labels).

Here's an example of using these new methods in Go:

```go
c, _ := dagger.Connect(ctx, dagger.WithLogOutput(os.Stdout))

gitTag := "v0.3.10"
repo :=
c.Git("https://github.com/dagger/dagger.git").Tag(gitTag).Tree()
daggerBinary := c.Container().From("golang:1.19-alpine3.17").
    WithMountedDirectory("/src", repo).
    WithEnvVariable("CGO_ENABLED", "0").
    WithWorkdir("/src").
    WithExec([]string{"go", "build", "-o", "dagger", "./cmd/dagger"}).
    File("dagger")

publishTarget := "fake.registry.invalid/test/publish:latest"
labelName := "dagger.version"
_, err := c.Container().From("gcr.io/distroless/static-debian11")
     .WithFile("/bin/dagger", daggerBinary).
     WithLabel(labelName, gitTag).
     Publish(ctx, publishTarget)
if err != nil {
    return err
}

labelVal, err := c.Container().From(publishTarget).Label(ctx, labelName)
if err != nil {
    return err
}
fmt.Println(labelName, "=", labelVal)
```

### SDK Highlights

We've also released new versions of our SDKs with support for all the new features in Dagger 0.3.10, plus various SDK-specific bug fixes and improvements.

#### Targeted Builds

All SDKs now have an improved Build() method that allows users to build a particular target in a multi-stage Dockerfile. This was a frequently requested feature from the community. Here's an example using the Nodejs SDK:

```javascript
import { connect } from "@dagger.io/dagger";

connect(async (client) => {
    const src = client
    .directory()
    .withNewFile("Dockerfile",
      `FROM node:16-slim AS base
       CMD echo "base"
       FROM base AS stage1
       CMD echo "stage1"
       FROM base AS stage2
       CMD echo "stage2"
       `
    )

      const output = await client.container().build(src, { target: 
  "stage1" }).withExec([]).stdout()

    // This will output "stage1"
    console.log(output)
  
  }, { LogOutput: process.stdout })
```

#### Improved Error Messages

The Python SDK now provides more verbose error messages whenever a Dagger session connection cannot be established. This makes it quicker and easier to debug failed sessions. Here's an example:

Before

```
dagger.exceptions.ProvisionError: Dagger engine failed to start
```

After

```
dagger.exceptions.SessionError: Dagger engine failed to start:Command 
'dagger/dagger-0.3.9 session' returned non-zero exit status 1.Error: 
failed to run container: docker: Cannot connect to the Docker daemon 
at unix:///var/run/docker.sock.Is the docker daemon running?.
```

#### Other Improvements

For a complete list of improvements, refer to the changelog for each SDK:

* Go SDK 0.4.4 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fgo%2Fv0.4.4) and [documentation](https://pkg.go.dev/dagger.io/dagger)
* Node.js SDK 0.3.2 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fnodejs%2Fv0.3.2) and [documentation](https://docs.dagger.io/current/sdk/nodejs/reference/modules)
* Python SDK 0.3.1 [changelog](https://github.com/dagger/dagger/releases/tag/sdk%2Fpython%2Fv0.3.1) and [documentation](https://dagger-io.readthedocs.org/)

### New Documentation

Interested in using Dagger with GitHub? We've added a new end-to-end tutorial that teaches you how to use a Dagger pipeline to continuously build and deploy a Node.js application with GitHub Actions.

[Read the tutorial](https://docs.dagger.io/sdk/nodejs/620941/github-google-cloud/)

\
We look forward to releasing more features and documentation soon! In the meanwhile, if you have feedback or would like to suggest new features or documentation, let us know on [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).

Dagger 0.3.10: New pipeline API, support for container metadata, and more

Dagger's approach to building CI/CD pipelines is unique. Our [SDKs](https://docs.dagger.io/#which-sdk-should-i-use) let you develop your pipelines as code, in a programming language you already know, and then execute those pipelines as standard [OCI containers](https://opencontainers.org/). This approach is both supremely portable and consistent (because your pipeline runs the same way locally and in a remote CI environment) and it has the added bonus of compatibility with the existing Docker ecosystem.

One of the most common questions users ask when first encountering Dagger is, "I already have a Dockerfile, why should I use Dagger?" And the answer (like most good answers) depends very much on the intended use case.

### Usage Scenarios

It's true that for most small and medium size projects without complex CI/CD needs, a Dockerfile can (and does) get the job done. But there are a number of scenarios where replacing a Dockerfile with a Dagger pipeline can yield significant benefits. Here are a few:

* Replacing monolithic CI dependency images: Sometimes, teams maintain one giant everything-including-the-kitchen-sink Dockerfile containing multiple dependencies so they only have to reference one image (like `myorg/ci`) in all their CI pipelines. Building and pushing these Dockerfiles becomes quite a chore, and teams must also deal with registry rate limits (if using a public registry) or maintain a private registry instead. Dagger lets you maintain images purely as code, so you never have to worry about building and pushing gigantic monolithic CI images.
* Sharing data between CI pipelines and application code: Since your Dagger pipeline is usually written in the same language as your application, it's much easier to share data between the two. For example, if you have a constant (like an image name) that you use in your actual production codebase, you can import it directly into your CI code rather than attempting to pass it as a Dockerfile argument.
* Greater re-usability and abstraction: Dagger lets you use general purpose programming languages and therefore supports more re-usability and abstraction. You can access native control structures like conditionals and loops, benefit from the language's existing testing tools, and add new functionality or integrate with third-party services using community extensions or packages. These operations are either extremely awkward or unsupported in the standard Dockerfile model, but very easy with Dagger. By the same token, Dagger pipelines also benefit from static typing and easier refactoring.
* Gradually rewriting a legacy Dockerfile: Sometimes you are stuck with a Dockerfile that is both very important, and painful to use. Everyone knows it should be replaced with something more powerful, ideally using a real programming language - but rewriting it all at once, without breaking compatibility, is too hard, so it never happens. Since Dagger can natively run Dockerfiles with full compatibility, it’s easy to wrap your existing Dockerfile in a Dagger pipeline, and gradually refactor it over time, without breaking your team’s workflow.

### Getting Started

If you've struggled with one or more of these scenarios, or if you're just curious about how it all works, we've put together a brief [guide on replacing a Dockerfile with a Dagger pipeline](https://docs.dagger.io/205271/replace-dockerfile). This guide explains how to use the Dagger Go SDK to perform all the same operations that you would typically perform with a Dockerfile. 

It illustrates the process by replacing the Dockerfile for the popular open source Memcached caching system with a Dagger Go pipeline and covers the following common tasks:

* Create a Dagger client in Go
* Write a Dagger pipeline in Go to:
* Configure a container with all required dependencies and environment variables
* Download and build the application source code in the container
* Set the container entrypoint
* Publish the built container image to Docker Hub
* Test the Dagger pipeline locally

We hope you find this guide useful and look forward to releasing more such guides soon! In the meanwhile, if you have feedback or would like to suggest new features or documentation, let us know in [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).

Replacing your Dockerfile with Go code

It's been three weeks since we released the [Dagger Node.js SDK 0.1.0](https://dagger.io/blog/nodejs-sdk). Since then, we've received many questions and suggestions from the community and we've incorporated several of them in our latest release, the Dagger Node.js SDK 0.3.0.

This version introduces two breaking API changes. However, we believe the improved API allows you to write much shorter code, which is significantly better in the long run.

[Get Started](https://docs.dagger.io/sdk/nodejs/783645/get-started)

### Dagger Node.js SDK 0.3.0 Highlights

#### Optional parameters as objects

You can now use objects for optional parameters. 

* Required parameters can be provided directly to functions as positional arguments.
* Optional parameters can be provided through an object that lets you mix and match the options you want. 

B﻿efore: 

```javascript
const source = await 
client.container().from(“alpine:16”).withExec([“echo”, “foo”], 
undefined, undefined, undefined, true)
```

A﻿fter: 

```
const source = await 
client.container().from('alpine').withExec(['echo', 'foo'], 
{experimentalPrivilegedNesting: true})
```

[Read the SDK documentation](https://docs.dagger.io/current/sdk/nodejs/reference/modules)

#### Less boilerplate

You no longer need to pass IDs, which makes the code you need to write much shorter. 

B﻿efore: 

```
const source = await client.host().directory(".").id()
const c = await client
    .container()
    .from("node:16")
    .withMountedDirectory("/src", source.id)
```

A﻿fter: 

```
const source = client.host().directory(“.”)
const c = await client
    .container()
    .from("node:16")
    .withMountedDirectory("/src", source)
```

[Read the SDK documentation ](https://docs.dagger.io/current/sdk/nodejs/reference/modules)

#### Centralized error handling

Debugging and error handling is faster and easier with new, more precise error messages and codes. 

B﻿efore: 

```
file:///home/user/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:255
        	throw new Error("failed to read port from engine session");
              	^
Error: failed to read port from engine session
	at DockerImage.<anonymous> (file:///home/dolanor/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:255:19)
	at Generator.next (<anonymous>)
	at fulfilled
```

A﻿fter: 

```
Error: buildkit failed to respond
file:///home/user/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:262
        	throw new EngineSessionPortParseError("No line was found to parse the engine port");
              	^
EngineSessionPortParseError [EngineSessionPortError]: No line was found to parse the engine port
	at DockerImage.<anonymous> (file:///home/dolanor/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:262:19)
	at Generator.next (<anonymous>)
	at fulfilled (file:///home/dolanor/src/demos/node_modules/@dagger.io/dagger/dist/provisioning/docker-provision/image.js:4:58)
	at processTicksAndRejections (node:internal/process/task_queues:95:5) {
  cause: undefined,
  code: 'D103'
}
```

[Learn more about the new error types](https://docs.dagger.io/current/sdk/nodejs/reference/modules/common_errors)

#### Improved filesystem API

We've added new methods to make it easier to work with the container filesystem

* `Container.WithDirectory`: returns the container plus a directory written at the given path.
* `Container.WithFile`: returns the container plus the contents of the given file copied to the given path.
* `Container.WithNewFile`: returns the container plus a new file written at the given path.

##### W﻿ithNewFile

B﻿efore: 

```
let textFile = fs.openSync("myTextFile", "w")
fs.writeFileSync(textFile, "my text content")

let packageFile = await client
    .host()
    .workdir(undefined, ["myTextFile"])
    .id()

await client
    .container()
    .from("node")
    .withMountedDirectory("/tmp/filedir", packageFile.id)
    .exec([ "cat", "/tmp/filedir/myTextFile" ])
    .stdout()
    .contents()
```

A﻿fter: 

```
await client
    .container()
    .from("node")
    .withNewFile("/tmp/filedir/myTextFile", { contents: "my text content" })
    .withExec([ "cat", "/tmp/filedir/myTextFile" ])
    .stdout()
```

[Read the SDK documentation](https://docs.dagger.io/current/sdk/nodejs/reference/classes/api_client_gen.Container)

We believe these changes bring the overall experience of using the SDK closer to what Node.js developers expect and use elsewhere, and also result in shorter and more readable code.

Thank you to the Dagger Community for your continuous and quick feedback. We look forward to releasing more features and documentation soon! In the meanwhile, if you have feedback or would like to suggest new features or documentation, let us know on [Discord](https://discord.com/invite/dagger-io) or create a [GitHub issue](https://github.com/dagger/dagger/issues/new/choose).

Dagger Node.js SDK 0.3: API improvements, better error handling and less boilerplate


Here at Dagger, we are on a mission to make your CI/CD pipelines programmable in the language of your choice. In the last few weeks, we have made great progress towards that goal by releasing SDKs for [Go](https://dagger.io/blog/go-sdk), [Python](https://dagger.io/blog/python-sdk), [Javascript and Typescrip](https://dagger.io/blog/nodejs-sdk)t in rapid succession. So rapid in fact, that some of you wondered how exactly we managed to pull it off!

[![Tweets](/img/screen-shot-2022-11-30-at-1.15.40-pm.png "Tweet References")](https://twitter.com/felipecruz/status/1593297610919628800)

Here’s the answer: we were cheating. Our SDKs don’t actually run your pipelines! Instead they send pipeline definitions to the Dagger Engine, which runs them and returns the result in a language-agnostic way.

Under the hood, we use a powerful API technology called [GraphQL](https://graphql.org/). And as of today, **so can you**. We are excited to publicly release the Dagger GraphQL API: a unified interface for programming the Dagger Engine using any standard GraphQL client.

[![GraphQL diagram](/img/dagger_graphql-diagram_01.png "Where the GraphQL API fits in the Dagger architecture")](https://docs.google.com/document/d/1QOG3ydXjfj9zA6W09ENecvAQvUiTEuDRVPPpT-PEOrA/edit#)

This release includes:

- [API documentation](https://docs.dagger.io/api), including guides, examples and a complete reference.
- An [API playground](https://play.dagger.cloud/) to run pipelines straight from your browser!
- A [new CLI](https://docs.dagger.io/cli) to run pipelines directly from the command-line

![playground gif](/img/solomon-playground-short.gif "Run CI/CD pipelines straight from your browser with the Dagger API playground!")

#### What does this mean for me?

First, and most importantly, if you are currently using a Dagger SDK, you can safely ignore this announcement and continue using Dagger exactly as before.

However, this release creates exciting new possibilities for the Dagger platform:

1. **Developers** can now use Dagger to program their CI/CD pipelines in over 20 languages, thanks to [GraphQL’s large and growing list of client implementations](https://graphql.org/code/#language-support). Note that the experience of using a standard GraphQL client is not the same as an official Dagger SDK. This is because “vanilla” clients follow the current state of the art in GraphQL development, which requires developers to write their queries manually (ideally with the help of an [interactive playground](https://play.dagger.cloud)). Dagger SDKs on the other hand automatically generate client libraries to hide the underlying GraphQL language, for a more native and polished experience. Developers that already know and love GraphQL may prefer the “vanilla” method; others will prefer official SDKs when they are available. Besides the aesthetic preferences, both are equally robust and full-featured. Going forward, we will continue to expand the list of available SDKs, and make it easier for the community to contribute new SDKs.
2. **Devops engineers** can use the new CLI to [run pipelines on-the-fly from the terminal or a shell script](https://docs.dagger.io/cli/389936/run-pipelines-cli). This can be used for experimentation, troubleshooting, and to retrofit Dagger pipelines into any system that can run shell commands, including: Makefiles, Jenkinsfiles, Github workflows, Gitlab pipelines, CircleCI configurations, Ansible playbooks, and many more.
3. There are many ways to develop a Dagger pipeline, but only one way to run them: by sending GraphQL queries to the Dagger Engine. This gives **infrastructure engineers** a natural insertion point to control every aspect of how pipelines are run, regardless of how they were developed. Whether it’s engine provisioning, logging, monitoring, authentication, authorization, networking, artifact management, or any other aspect of a robust and secure CI infrastructure: Dagger’s architecture allows for all of it to be configured or overridden by the operator. This will be the primary focus of our roadmap in the coming weeks.

#### Why GraphQL?

Engineers are generally not known for agreeing on things - we like to argue! But one thing we all seem to agree on is that the CI/CD experience is often frustrating, and should be improved. But how?

![yaml test](/img/ga-actions.png "yaml test")

We believe the answer is to decouple pipeline _logic_ from pipeline _infrastructure_, which in turn allows decoupling the concerns of application and infrastructure teams. This can be achieved with a powerful architectural pattern called the [hourglass model](https://arxiv.org/pdf/1607.07183.pdf): the same pattern that enabled the Internet, Unix, and more recently, Docker.

To apply the hourglass pattern to CI/CD we need an API expressive enough to connect the two parts of the hourlgass: run any pipeline logic, on any pipeline infrastructure - and do it well.

That is where GraphQL comes in. GraphQL is a perfect fit for the CI/CD “hourglass”, for three reasons:

1. **Technical**: GraphQL is fundamentally a graph traversal language. And it turns out that pipeline execution is fundamentally a graph traversal problem - it’s no coincidence that “Dagger” starts with “[DAG](https://en.wikipedia.org/wiki/Directed_acyclic_graph)”! Our early prototypes ended up looking so much like GraphQL, that it quickly became obvious that we should just build on top of it instead of reinventing the wheel.
2. **Human:** GraphQL was designed to decouple concerns between frontend and backend teams, by enabling frontend teams to compose queries themselves from building blocks provided by the backend team. Meanwhile, Dagger seeks to decouple concerns between application and infrastructure teams, by enabling application teams to compose pipelines themselves from building blocks provided by the infrastructure team. In both case, decoupling of concerns allows everyone to be happier and more productive.
3. **Ecosystem**: no one company can solve this problem alone. We are already standing on the shoulders of giants by leveraging the container ecosystem. Thanks to the GraphQL ecosystem we are now standing on the shoulders of TWO GIANTS! Every time anyone in the GraphQL and container ecosystem solves a problem for themselves, they are also solving it for everyone in the Dagger ecosystem.

Ready to give it a try? You can follow our [introduction guide](https://docs.dagger.io/api/254103/build-custom-client), browse the [API reference](https://docs.dagger.io/api/reference/), or [experiment with the API playground](https://play.dagger.cloud).

As always, we love hearing from you, let us know how you enjoy using the API, and what cool things you build with it.

Happy coding!


Introducing the Dagger GraphQL API

Today we are proud to introduce the [Node.js SDK](https://docs.dagger.io/sdk/nodejs): a new way to develop your CI/CD pipelines as code and run them anywhere.\
​

**The Dagger Node.js SDK may be a good fit if you are...**

* A front-end or back-end end developer wishing your CI pipelines were TypeScript or JavaScript code that you can run locally in seconds, instead of YAML that can only run on a proprietary service
* A developer who needs CI/CD, and is looking for an excuse to learn TypeScript or JavaScript
* Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful
* A platform engineer writing custom TypeScript tooling, with the goal unifying continuous delivery across organizational silos

This is our third SDK release in the past month, after [Go](https://dagger.io/blog/go-sdk) and [Python](https://dagger.io/blog/python-sdk). Our ultimate goal is to ensure all developers can develop their CI/CD pipelines in the same way they develop the rest of their code. If you are looking for a different SDK, [let us know](https://airtable.com/shrzABOn1wCk5yBF4). You can also subscribe to **[our newsletter](http://eepurl.com/hzIma5)** to be notified of future SDK launches.

**What is Dagger again?**

Dagger is a programmable CI/CD engine that runs your pipelines in containers.

**Programmable:** develop your CI/CD pipelines as code, in the same programming language as your application.

**Runs your pipelines in containers:** Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). This has several benefits:

* Instant local testing
* Portability: the same pipeline can run on your local machine, a CI runner, a dedicated server, or any container hosting service.
* Superior caching: every operation is cached by default, and caching works the same everywhere
* Compatibility with the Docker ecosystem: if it runs in a container, you can add it to your pipeline
* Cross-language instrumentation: teams can use each other’s tools without learning each other’s language

![diagram](/img/screen-shot-2022-10-25-at-9.22.41-am.png "diagram")

### **Dagger Node.js in Action**

In this demo, we’ll show you how to create a CI tool to test your Node.js application against multiple Node.js versions.

<iframe width="90%" height="400px" src="https://www.youtube.com/embed/cuqmq_aTNfY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

**Want to try it yourself? Check out our [Getting Started Guide](https://docs.dagger.io/sdk/nodejs/783645/get-started).** 

##### **Want to Get Involved?**

We have lots of ways to contribute and stay engaged with Dagger updates. We look forward to seeing you in our community forum:

* Join us on [Discord](https://discord.gg/dagger-io)
* [Report an issue or tell us about your use case](https://github.com/dagger/dagger/issues/new/choose)
* Join our weekly community call or meet up with us at an event. Check out the [events page](https://dagger.io/events) to see the latest!

Introducing the Dagger Node.js SDK

Today we are proud to introduce the [Dagger Python SDK](https://docs.dagger.io/sdk/python): a new way to develop your CI/CD pipelines as code and run them anywhere.

​
**The Dagger Python SDK may be a good fit if you are...**

* A Python developer wishing your CI pipelines were Python code that you can run locally in seconds, instead of YAML that can only run on a proprietary service
* A developer who needs CI/CD, and is looking for an excuse to learn Python
* Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful
* A platform engineer writing custom Python tooling, with the goal of unifying continuous delivery across organizational silos
* A data engineer looking to better integrate with your organization's CI/CD pipelines.

Just two weeks ago we announced the [Dagger Go SDK](https://docs.dagger.io/sdk/go), and will continue to release more SDKs in the future. Our ultimate goal is to ensure all developers can develop their CI/CD pipelines with the language of their choice, and enjoy all the benefits of running them with Dagger.

If you are looking for a different SDK, let us know by [filling this form](https://airtable.com/shrzABOn1wCk5yBF4). We will notify you when your SDK is ready.

**What is Dagger again?**

Dagger is a programmable CI/CD engine that runs your pipelines in containers.

**Programmable:** develop your CI/CD pipelines as code, in the same programming language as your application.

**Runs your pipelines in containers:** Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). This has several benefits:

* Instant local testing
* Portability: the same pipeline can run on your local machine, a CI runner, a dedicated server, or any container hosting service.
* Superior caching: every operation is cached by default, and caching works the same everywhere
* Compatibility with the Docker ecosystem: if it runs in a container, you can add it to your pipeline
* Cross-language instrumentation: teams can use each other’s tools without learning each other’s language

![Diagram](/img/screen-shot-2022-10-25-at-9.22.41-am.png "Diagram ")

### **Dagger Python SDK in Action**

In this demo, we’ll show you how to create a CI tool to test your Python application against multiple Python versions.

<iframe width="90%" height="400px" src="https://www.youtube.com/embed/c0bLWmi2B-4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

**Want to try it yourself? Check out our [Getting Started Guide](https://docs.dagger.io/sdk/python/628797/get-started).** 

##### **Want to Get Involved?**

We have lots of ways to contribute and stay engaged with Dagger updates. We look forward to seeing you in our community forum:

* Join us on [Discord](https://discord.gg/dagger-io)
* [Report an issue or tell us about your use case](https://github.com/dagger/dagger/issues/new/choose)
* Join our weekly community call or meet up with us at an event. Check out the [events page](https://dagger.io/events) to see the latest!

Develop your pipelines as code with the Dagger Python SDK

As you might have seen, we released the [Dagger Go SDK 0.3.0](https://dagger.io/blog/go-sdk) early last week. Thanks to your many questions and suggestions, we were able to ship several additional improvements, which we are releasing today as the Dagger Go SDK 0.4.0.

Note that this version introduces a breaking API change. However, we believe the improved API allows you to write much shorter code, which is significantly better in the long run.

**[Get Started](https://docs.dagger.io/sdk/go)** 

### Dagger Go SDK 0.4 Highlights:

#### Multi-platform pipelines

* Dagger now supports pulling container images and executing commands on platforms that differ from the underlying host.
* For example, you can use Dagger to compile binaries that target different CPU architectures, test those binaries and push them to a registry bundled as a multi-platform container image, all on a single host. 

**[Learn more about Dagger’s multi-platform support](https://docs.dagger.io/sdk/go/406009/multiplatform-support/)**

#### Improved filesystem API

* Import any directory from the host filesystem with `Host.Directory.` This replaces the more cumbersome LocalDirs, `Host.Workdir` and `HostDirectory.Read`
* Export any directory to the host filesystem with `Directory.Export`. This replaces `HostDirectory.Write` 
* Export any file to the host filesystem with `Directory.Export`
* Export any container to an OCI archive on the host filesystem with `Container.Export`. 
* `Host.Directory`, `Host.Workdir`, and `Directory.WithDirectory` now support `include:/exclude:` params for filtering the set of files to select.

**[See more examples of working with the host filesystem](https://docs.dagger.io/421437/work-with-host-filesystem/)**

#### Less boilerplate

You no longer need to pass IDs, which makes the code you need to write much shorter. See the example below: 

Before: 

```
modules := c.Directory()
for _, f := range []string{"go.mod", "go.sum", "sdk/go/go.mod", "sdk/go/go.sum"} {
	fileID, err := workdir.File(f).ID(ctx)
	if err != nil {
		return err
	}

	modules = modules.WithCopiedFile(f, fileID)
}
```

After: 

```
modules := c.Directory()
for _, f := range []string{"go.mod", "go.sum", "sdk/go/go.mod", "sdk/go/go.sum"} {
	modules = modules.WithCopiedFile(f, workdir.File(f))
}
```

**[Read the API documentation](https://pkg.go.dev/dagger.io/dagger)**

### New Documentation

Along with the new release, we’ve added four [guides](https://docs.dagger.io/sdk/go/275922/guides/) to our [documentation](https://docs.dagger.io/) that answer the most common questions we’ve heard in the days following the initial release. We hope these guides will help you make the most of the Go SDK.

* [Work with the Host Filesystem](https://docs.dagger.io/421437/work-with-host-filesystem/): This guide explains how to interact with the host filesystem using the Go SDK. It includes code examples of setting the working directory on the host, mounting a host directory in a container, exporting a directory from a container to the host, and more.
* [Understand Multi-Platform Support](https://docs.dagger.io/sdk/go/406009/multiplatform-support/): This guide demonstrates different techniques to build applications for multiple platforms using the Go SDK. It includes code examples of building multi-platform applications using emulation and cross-compilation.
* [Copy Embedded Directories into a Container](https://docs.dagger.io/110632/embed-directories/): This guide explains how to copy an entire directory tree from a host to a container.
* [Use Dagger with Private Git Repositories](https://docs.dagger.io/sdk/go/710884/private-repositories/): You can use `ssh-add` to securely authenticate your Dagger Go CI pipeline against private Git repositories.This guide shows you how. 

Thank you to the Dagger Community for your continuous and quick feedback through our **[Discord channel](https://discord.com/invite/dagger-io)** and **[GitHub issues](https://github.com/dagger/dagger/issues/new/choose)**. We look forward to releasing more features and documentation soon! 

Are you looking for updates on a different SDK? Fill out this **[form](https://blocklayer.typeform.com/to/a6m5gKSS?typeform-source=dagger.io)**, and we will notify you when your SDK is ready. 

Do you have feedback on our documentation? Would you like to suggest a new guide? Send us your feedback and ideas in our **[Discord channel](https://discord.com/invite/dagger-io)** or **[open a new issue on GitHub](https://github.com/dagger/dagger/issues/new?assignees=&labels=area%2Fdocumentation&template=documentation.yaml).**

Dagger Go SDK 0.4: multi-platform, improved filesystem API and more

Today we are proud to introduce the [Dagger Go SDK](https://docs.dagger.io/sdk/go): a new way to develop your CI/CD pipelines as code and run them anywhere.[​](https://devel.docs.dagger.io/8g34z/get-started-sdk-go/#who-is-it-for)

**The Dagger Go SDK may be a good fit if you are...**

* A Go developer wishing your CI pipelines were Go code that you can run locally in seconds, instead of YAML that can only run on a proprietary service
* A developer who needs CI/CD, and is looking for an excuse to learn Go
* Your team's "designated devops person", hoping to replace a pile of artisanal scripts with something more powerful
* A platform engineer writing custom Go tooling, with the goal unifying continuous delivery across organizational silos
* A cloud-native developer advocate or solutions engineer, looking to demonstrate a complex integration on short notice

**The Dagger Go SDK may not be a good fit if you are...**

* A developer who doesn't know Go, and is not interested in learning it. If you are looking for another SDK, let us know [here](https://airtable.com/shrzABOn1wCk5yBF4). We will notify you when your SDK is ready.
* A "designated devops person" who doesn't think of themselves as a developer - nothing makes you happier than a battle-hardened shell script.
* Someone who loves programming in YAML, thank you very much.
* A container skeptic: the less containers are involved, the happier you are.

In the future, we will release more SDKs. Our ultimate goal is to ensure all developers can develop their CI/CD pipelines in the same way they develop the rest of their code. If you are looking for a different SDK, [let us know](https://dagger-io.typeform.com/to/a6m5gKSS). If you fill out the form, we will notify you when your SDK is ready!

**What is Dagger again?**

Dagger is a programmable CI/CD engine that runs your pipelines in containers.

**Programmable:** develop your CI/CD pipelines as code, in the same programming language as your application.

**Runs your pipelines in containers:** Dagger executes your pipelines entirely as [standard OCI containers](https://opencontainers.org/). This has several benefits:

* Instant local testing
* Portability: the same pipeline can run on your local machine, a CI runner, a dedicated server, or any container hosting service.
* Superior caching: every operation is cached by default, and caching works the same everywhere
* Compatibility with the Docker ecosystem: if it runs in a container, you can add it to your pipeline
* Cross-language instrumentation: teams can use each other’s tools without learning each other’s language

![Dagger Diagram ](/img/screen-shot-2022-10-25-at-9.22.41-am.png "Dagger Diagram ")

#### Dagger Go SDK in Action

In this demo, you will see how quickly you can create a Go CI tool that builds a Go application with multiple architectures and Go versions using the Dagger Go SDK.

<iframe width="90%" height="400px" src="https://www.youtube.com/embed/GgMskf-znh4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

**Want to try it yourself? Check out our [Getting Started Guide](https://docs.dagger.io/sdk/go/).**

##### **Want to Get Involved?**

We have lots of ways to contribute and stay engaged with Dagger updates. We look forward to seeing you in our community forum:

* Join us on [Discord](https://discord.gg/dagger-io)
* [Report an issue or tell us about your use case](https://github.com/dagger/dagger/issues/new/choose)
* Join our weekly community call or meet up with us at an event. Check out the [events page](https://dagger.io/events) to see the latest!

Your CI pipelines should be code: introducing the Dagger Go SDK

A few days after [launching the public beta of Dagger](https://dagger.io/blog/public-launch-announcement), we asked the community a simple question: [how can we improve our developer experience](https://github.com/dagger/dagger/discussions/2052)? The most popular request was for a [VS Code](https://en.wikipedia.org/wiki/Visual_Studio_Code) extension with proper [Language Server](https://en.wikipedia.org/wiki/Language_Server_Protocol) integration. So we took the community's advice and got to work.

Today, we're happy to introduce the first version of [Dagger for VS Code](https://marketplace.visualstudio.com/items?itemName=Dagger.dagger), bringing a first-class Dagger development experience straight to one of the world's most popular IDE. We're also open-sourcing [our LSP implementation for CUE](https://github.com/dagger/cuelsp), so that every other IDE and text editor can benefit from an improved CUE development experience as well. For example, here is a [guide for adding CUE LSP support to vim](https://github.com/dagger/cuelsp/blob/main/docs/vim.md).

#### Features

For the first release, Dagger for VS Code includes three features: *jump to definition*; *hover*; and *syntax highlighting*. All three features can be used from other IDEs, using the [cuelsp implementation](https://github.com/dagger/cuelsp).

##### Jump to Definition

![Jump to Definition Example](/img/jump-to-def.gif)

Now, we have a simple way to explore the [Dagger Universe](https://universe.dagger.io) and all its definitions. The Dagger Universe is a collection of reusable components, so we can use the “go to definition” feature to pick the one you need quickly.

##### Hover

![Hover Example](/img/hover.gif)

You will need a basic understanding of [CUE definitions](https://cuetorials.com/overview/foundations/#definitions) to get the most out of Dagger. To decrease the learning curve, we have added the ability to show references inline. This provides an easy way to see the overall description of an action and its internal type.

When using “go to definition” and “show definitions”, you will have a complete overview of all CUE definitions used in your Dagger project.

##### Syntax highlighting

We took inspiration from the Golang syntax to create our LSP theme so you can find the essential information quickly.

![lsp theme](/img/lsp-theme.png)

#### What’s an LSP?

A Language Server Protocol (LSP) is a standard used between an editor and a language server to provide language-specific features like auto(completion), go to definition, show references, etc. An LSP is a developer's best friend since it enables an easier way of exploring and understanding code libraries, directly from your code editor:

![LSP Example](/img/buildkit-schema-2-1-.png)

#### The CUE LSP challenge

Creating a CUE language server differs from standard languages like Golang, Python, or C++. In a typical language server, you work directly with the files and interpret them to provide language features.

With CUE, it’s the same, but you also need to work with the CUE engine to compile CUE values to simplify the implementation further.

When creating the Dagger CUE LSP, this constraint added a layer of complexity that we addressed by building a multi-component architecture. We decided to split the responsibility of file loading, jump to definition, hover, etc., into small pieces of code so we can extend it with new features later.

This resulted in the architecture below:

![Dagger CUE LSP Architecture](/img/lip-architecture-1-.png)

#### What’s next?

If you're using VS Code, give [the Dagger extension](https://marketplace.visualstudio.com/items?itemName=Dagger.dagger) a try! If you are using vim, [follow our CUE LSP setup guide](https://github.com/dagger/cuelsp/blob/main/docs/vim.md).

We love hearing from you! To give us feedback, you can [start a discussion](https://github.com/dagger/dagger/discussions), [create an issue](https://github.com/dagger/dagger/issues/new/choose), or [join our Discord server](https://discord.gg/ufnyBtc8uY).


Introducing Dagger for VS Code with CUE LSP support


There’s a running joke in the developer community that the physical supply chain–the one moving goods around the globe– is far more efficient than the software supply chain. And with essentially all computing moving to the cloud, software supply chains are growing in size and complexity. Devops engineers tasked with automating them are under increasing pressure to break through the bottleneck.

My co-founders [Sam Alba](https://twitter.com/sam_alba), [Andrea Luzzardi](https://twitter.com/aluzzardi) and I had seen the same problem time and time again: burned out devops teams trying their hardest to cobble together deployment pipelines that are nearly impossible to scale or port to other cloud platforms. The app deployment experience is painful, and solving this problem is the holy grail of devops.

This is the problem that we aspire to solve with Dagger. Devops engineers using Dagger get a standardized set of building blocks that they can assemble any way they want, knowing that the result will run reliably on any cloud. We’ve been working with some of the best engineers in the world to develop the platform and are [excited to launch the public beta version today](https://dagger.io/blog/public-launch-announcement).

And we’re just getting started. Today, we also announce the closing of a $20 million Series A investment led by Redpoint Ventures, with participation from Y Combinator, Nat Friedman (former CEO, Github), Brian Stevens (former CTO, Google Cloud and former CTO, Red Hat), Idit Levine (founder and CEO, solo.io), Julius Volz (creator of Prometheus), Ellen Pao (former CEO, Reddit), Daniel Lopez (co-founder, Bitnami), and others. Erica Brescia at Redpoint will be an invaluable asset as the newest addition to our board. Erica has been a leader in the devops space for over a decade, as the former co-founder of Bitnami (acquired by VMWare) and former COO of GitHub. We couldn’t imagine a better partner to build an industry-defining platform business.

We would also like to take the opportunity to thank [New Wave](https://newwave.vc), who led our $7 million seed funding round last year. As European founders we are proud to count a European fund as one of our major investors, proof that excellence in venture capital has no borders. Our total funding raised now amounts to $30 million, and we’re thrilled to keep growing our team and developing the Dagger platform with the open source community.

If you or anyone you know wants to join the team building the next stage of the devops revolution, [we would love to chat](https://dagger.io/careers).


Announcing our $20M Series A from Redpoint Ventures


Hi! We’re the creators of Docker, and today we’re proud to introduce our new project, [Dagger](https://dagger.io). Dagger is a portable devkit for CI/CD pipelines. It allows devops engineers to build powerful CI/CD pipelines quickly, then run them anywhere. Benefits include: unifying dev and CI environments; testing and debugging pipelines locally; and avoiding CI lock-in. Most importantly, it introduces an ecosystem of truly composable software components: a “lego system” which we hope will help the devops community solve its fragmentation problem. Under the hood, Dagger is powered by two of the most exciting technologies in the cloud-native ecosystem: [Buildkit](https://github.com/moby/buildkit) and [CUE](https://cuelang.org).

We’ve been developing Dagger together with a community of early adopters. Now we are ready to continue developing it [in the open](https://github.com/dagger/dagger). If you’d like to participate, [join us on Discord!](https://discord.gg/dagger-io).

To our alpha and private beta testers: _thank you_ for investing your time and energy to help us test, review and develop Dagger. We dedicate this launch to you, and we cannot wait to grow this community together.

We’re also hiring! If you’d like to help us improve the lives of devops engineers, [we’d love to talk to you](https://dagger.io/careers).

#### Why Dagger?

##### A developer’s dream is a devops engineer’s nightmare

![engineer automating delivery](/img/cicd-fragmented.png)

There’s never been a better time to be a developer. Thanks to an ever-expanding selection of specialized tools and cloud infrastructure, a dedicated team of developers can ship a competitive product in almost any industry within months. The result is unprecedented growth and innovation at every level of the stack.

This developer’s dream creates a nightmare for devops engineers, whose job is to automate the delivery of increasingly complex applications to increasingly complex cloud infrastructure. In order to continuously build, test and deploy their software, developers need a CI/CD pipeline that glues together an ever-expanding collection of specialized tools. The result is a mess of homemade scripts that are painful to write, difficult to debug and test, and must be rewritten for each new development and CI environment. Component reuse between pipelines is low, which causes fragmentation and a constant reinvention of the wheel.

##### Modernizing the CI/CD development experience

![astronaut writing a plan](/img/unifed-automated-resilient.png)

Dagger solves the devops engineer’s nightmare by telling them: “your pipelines are software. This makes you a developer, and you deserve a proper developer experience”. For example:

- Instead of gluing pipelines together with throwaway scripts, they can “play lego” by composing reusable actions, using an intuitive declarative language and API.
- Actions can safely be shared and reused thanks to a complete package management system, and there is a growing catalog of open-source actions developed by the community.
- Pipelines can be tested and debugged locally, then run on any CI system
- All actions are automatically cached: no manual tweaking necessary

This allows devops engineers to continuously improve their pipelines, with the confidence afforded by modern development practices.

##### Write your pipeline once, run anywhere

![astronaut deploying](/img/write-pipeline-once.png)

Because Dagger runs equally well anywhere a Docker-compatible runtime is available, it eliminates two major problems in the devops experience: dev/CI drift, and CI lock-in.

- _Dev/CI drift_: instead of writing the same automation twice - once in a CI-specific configuration, and again in a Docker compose file, shell script or Makefile - simply write a Dagger plan once, then run it in all environments.
- _CI lock-in_: migrating from one CI system to another, or supporting teams with multiple CI systems, should not require rewriting entire pipelines from scratch! The same Dagger plan can be run without modification on all major CI systems.

#### What’s next?

Dagger is still in the early stages of development. Thanks to a [new round of funding](https://dagger.io/blog/series-a) we will continue to expand our team, and continue building the ultimate CI/CD experience: more portable, more productive… and more fun!

If you share our definition of fun, [come say hi](https://discord.gg/dagger-io)! Our community is open to all, from beginners to seasoned devops veterans. We look forward to building something great together.

Happy hacking!


Introducing Dagger: a new way to create CI/CD pipelines


#### Today we are proud to introduce dagger 0.2, codename Europa.

This is our first major release since the beginning of our private beta last year, and it is based entirely on your feedback.

To all of you who have invested the time to test our nearly 40 releases; to report issues, suggest improvements, contribute and review code and documentation: thank you! This release would not be possible without you.

#### Migrating from 0.1 to 0.2

Please note that, 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. Going forward, we plan to make backwards compatibility a priority, either by not breaking APIs, or providing seamless migration if we do. If you need help migrating your plan, we will be happy to assist you!

[Learn more about migrating to 0.2](https://docs.dagger.io/1214/migrate-from-dagger-0.1).

#### What's new in dagger 0.2?

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!

##### **One simple configuration for everything: the Plan**

We have radically simplified the process of setting up and configuring a pipeline. From having to learn half a dozen different commands and configuration files... to just one step: write the plan.

In Dagger 0.2, every aspect of your pipeline is controlled, declaratively, in your plan. In addition to making Dagger simpler to understand and use, it makes it natively compatible with declarative patterns such as gitops.
[Learn more about the Dagger Plan](https://docs.dagger.io/1202/plan).

##### **Lego for your pipelines: the Action API**

Dagger’s superpower is its lego-like composition model: simple actions can be composed to form a more complex one; which in turn can be composed again; and so on, until even the most complex pipelines can be assembled at a fraction of the usual cost, and at higher quality.

The foundation of this model is the Action API: a complete framework for composing arbitrarily complex automations out of standardized primitives, declaratively, using CUE and Buildkit.
[Learn more about the Action API](https://docs.dagger.io/1213/api).

##### **One simple command: dagger do**

We have simplified the dagger CLI so that anyone can intuitively understand what your pipelines do and how to use them, even if they’ve never used Dagger. No knowledge of CUE required!

Running a pipeline is as simple as _dagger do ACTION_. For example, _dagger do build_, _dagger do test_, _dagger do deploy_. Actions are loaded directly from your plan, so you can declaratively control your pipeline's command-line experience. Best of all, _dagger do --help_ dynamically loads available actions and presents them to the user.

##### **Integrate dagger anywhere: the Client API**

In dagger 0.2, a plan may use the Client API to interact with the client machine in a variety of ways: read or write to the filesystem; access environment variables; open network connections; query platform information; and even execute commands. This allows seamless integrations into your existing tooling and infrastructure.

For example, your development machine may have Docker credentials stored in the MacOS keychain; your CI runner may be configured to request ephemeral tokens for a specific profile before each AWS operation; or you may want to run tests against a local source code checkout. These integrations cannot be sandboxed in a container: they require access to the client machine. The Client API makes them possible in just a few lines of CUE.

[Learn more about the Client API](https://docs.dagger.io/1203/client)

##### **Secure by default: the Secrets API**

Secrets are a crucial part of any CI/CD pipeline, which is why Dagger introduced native support for secrets from the very beginning. Dagger 0.2 expands and improves this feature in several ways:

- Dagger secrets are never merged into the plan, which helps prevent credential leaks. And just in case you accidentally print a secret’s contents in your action logs… Dagger will automatically detect it and scrub it. You’re welcome!
- Using the new Client API, secrets can now be loaded from virtually any source: a file, an environment variable, a proprietary KMS, a vault service, a local keychain, etc.
- Actions can now dynamically create their own secrets, using the [\#NewSecret core action](https://github.com/dagger/dagger/blob/main/pkg/dagger.io/dagger/secrets.cue#L18).
- Actions can now perform common operations against the contents of a secret, securely, without accessing the contents directly (to avoid leaks). Operations include [extracting a secret from a JSON- or YAML-encoded envelope](https://github.com/dagger/dagger/blob/main/pkg/dagger.io/dagger/secrets.cue#L5), and [trimming space characters](https://github.com/dagger/dagger/blob/main/pkg/dagger.io/dagger/secrets.cue#L32).
- Secrets can now be injected into containers as environment variables, in addition to temporary files

[Learn more about the Secrets API](https://docs.dagger.io/1204/secrets)

---

#### Get involved!

Dagger is a community-driven project. We develop in the open, and anyone is welcome to join the fun, no matter how experienced. Whether you’re a seasoned engineer, or looking to make your first open-source contribution, there are many ways you can contribute. Come say hello [on our Discord server](https://dagger.us20.list-manage.com/track/click?u=78ddebf129e125c5037fd6f4d&id=bda77f8e8d&e=174ebdaff6 'https://dagger.us20.list-manage.com/track/click?u=78ddebf129e125c5037fd6f4d&id=bda77f8e8d&e=174ebdaff6')!


Dagger 0.3.10 Release: New pipeline API, support for container metadata, and more