Getting errors on sops.

Update: I'm blocked by the same issue as:

• Structural cycle when dagger do --with and dagger.#DecodeSecret are conjointly used #1867

I need to go back to a fix for it in order to move forward:

• Fix DecodeSecret output type #2024

Update: asked for feedback upstream on the blocker: cue-lang/cue#1671. Solution in #2024 allows to unblock.

👀 Updated doc preview

I tried filling from tasks to a r.final but got data races. So approach was to recover computed values and only fill at the end. This will be simplified in CUE v0.4.3 with cue-lang/cue@04ac666.

Ready for review.

Haven't looked in depth yet but looks good!

Q: Aren't the outputs polluted by random fields, or is there some logic to clean that up? (I looked at the logic of isOutput but couldn't find anything related to that).

For instance, for a netlify.#Deploy, shouldn't we see a bunch of noise in deploy.container (generated by bash.#Run)?

Q: Aren't the outputs polluted by random fields, or is there some logic to clean that up? (I looked at the logic of isOutput but couldn't find anything related to that).

For instance, for a netlify.#Deploy, shouldn't we see a bunch of noise in deploy.container (generated by bash.#Run)?

No because we're using only top-level fields of an action, not going deep. The netlify.#Deploy action is a good example as it correctly exports to the top-level what outputs are of interest:

	// URL of the deployed site
	url: container.export.files."/netlify/url"

	// URL of the latest deployment
	deployUrl: container.export.files."/netlify/deployUrl"

	// URL for logs of the latest deployment
	logsUrl: container.export.files."/netlify/logsUrl"

Which produces the output you can see here:

➜  APP_NAME=dagger-todo dagger do deploy
[✔] actions.deps
[✔] actions.test.script
[✔] client.env
[✔] actions.build.run.script
[✔] actions.deploy.container.script
[✔] client.filesystem."./".read
[✔] actions.deploy
[✔] actions.test
[✔] actions.build.run
[✔] actions.build.contents
[✔] actions.deploy.container
[✔] client.filesystem."./_build".write
[✔] actions.deploy.container.export
Field      Value
url        "https://dagger-todo.netlify.app"
deployUrl  "https://62698983ffe8661d60613431--dagger-todo.netlify.app"
logsUrl    "https://app.netlify.com/sites/dagger-todo/deploys/62698983ffe8661d60613431"

So you can create a wrapper action to control which outputs (and CLI inputs) you want, as you can see in this example: https://deploy-preview-2265--devel-docs-dagger-io.netlify.app/1226/handling-outputs/#controlling-the-output

The netlify.#Deploy action is a good example as it correctly exports to the top-level what outputs are of interest

Yes, I noticed the output is perfect, that's what got me wondering on what's the wizardry behind that makes it look good :)

No because we're using only top-level fields of an action

How do we define top-level fields? For instance:

• web contains build and deploy (build is yarn and deploy is netlify)
• web.deploy is netlify
• web.deploy.container is an internal field of netlify (bash.#Run)

web, deploy and container are actions in this case.

What would end up in outputs? Is it going to be the outputs of web only?

What would end up in outputs? Is it going to be the outputs of web only?

Yes 🙂

Ohh, clever! Makes sense -- this is the perfect counter part of --inputs, top-level only.