Today we are delighted to introduce Dagger 0.4.0, featuring service containers, secrets scrubbing, and more.
Service containers have been one of the most requested features. They are now finally available. This feature enables you to run network services - like databases or webapps - as ephemeral containers, directly inside a Dagger pipeline.
Some common use cases for this new feature are:
Run a test database
Run end-to-end integration tests
Run sidecar services
Service containers come with the following built-in features:
Service containers are started just-in-time, de-duplicated, and stopped when no longer needed
Service containers are health checked prior to running clients
Service containers are given an alias for the client container to use as its hostname
Using service containers
Binding a service to a container expresses a dependency: the service container needs to be running when the client container runs. The bound service container is started automatically whenever its client container runs.
Here's an example of creating an HTTP service and fetching from it:
WithExposedPort() method sets the ports that the container will listen on. Dagger checks the health of each exposed port prior to running any clients that use the service, so that clients don't have to implement their own polling logic.
Want to learn more about how services work in Dagger? Check out our documentation.
Dagger now automatically scrubs secrets from its various logs and output streams. This ensures that sensitive data does not leak - for example, in the event of a crash. This applies to secrets stored in both environment variables and file mounts.
Here's an example that demonstrates this in action:
The output will be:
We've also released new versions of our SDKs with support for all the new features in Dagger 0.4.0, plus various SDK-specific bug fixes and improvements.
For a complete list of improvements, refer to the changelog for each SDK: