check then release

[fluid arrow]

got it. If the checks pass, may I ask what the prerelease function does? In particular what side effects does it have on your infra?

do you want to auto-deploy to prod if checks pass? Or to trigger a smaller intermediary step, like pushing artifacts for future deployment, or deploying a preview environment?

[robust needle]

Intermediate, like running codegen, generating changelog/release note artifacts, etc. I could see users downstream wanting to do something similar on their own also like create their own checks for their projects and call them along with docker builds, etc. Nothing infra related, all git/registry push related

[safe totem]

This has also come up in my team as well. We probably want to call all the checks and then run the release. I can see the ability to programatically call checks both powerful but also potentially hazardous - it would be bad if you call checks which themselves called checks leading to infinite recursion

At the moment we are steering towards either two seperate steps in our github actions (i.e. call dagger checks, call release) OR having our release programatically call all required toolchain functions manually (which would otherwise be invoked via dagger checks)

[fluid arrow]

This topic - composition of checks & deployments - is important & not yet resolved.

We'll need a few months to try different patterns and see what works best. Then, we might introduce additional primitives to fill the gaps.

[fluid arrow]

A few notes:

1. In doubt, I recommend starting with a cleanly separated checks workflow. Anything that produces a red/green output that is an input to PR review, should be exposed as a dagger check, and called directly (not programmatically) via the dagger check CLI. Both during local dev & in CI

2. For codegen and other generated artifacts that will be in source control (generated API docs, changelog, client bindings, grpc stubs..) we are adding a first-class dagger generate backed by +generate functions, following the same model as checks. You should use that once we ship it 🙂 Decoupled from checks.

3. For actual deployments, for now no native entrypoint, just regular dagger call. This is where you will need to decide between the options listed by @safe totem . either a) function composition, or b) CI composition. We have the same problem for our own CI, will let you know what we end up doing, and we can keep figuring out best practices together

4. I can already tell you that we're going to split deployment in two parts: a) idempotent artifact publishing with no side effects , and b) "flipping the switch" and actually changing the state of the production system (new version served on the production endpoints, new versioned release). They are often bundled together but are actually very different. For example preview deployments per PR rely in a) without b). Once this is separated, we will most likely design a new dagger-native entrypoint for publishing artifacts. This will require figuring out the relationship between artifact publishing and checks.

5. Relevant to all this, are @pulsar dove 's ideas for transposing the groundbreaking ideas from Concourse CI around artifact-centric, declarative CI. We haven't yet found the best way to merge all these ideas into the new dagger stack, but we started the discussion & we will figure it out - it will be glorious 🙂