Replies: 5 comments
-
Great stuff 🙂
Me too! And it makes it more portable. (windows anyone?)
Yeah, that's also what I've been doing. You know I'm partial to this 🙂
Not aware of this. Want to know more.
This has been mentioned by multiple users.
Interesting. I've been through this in January a lot, but it was because of the nesting issue. I know how frustrating it is to break those steps into correctly hooked fields. One small typo and you have an error that's not the root cause (incorrect
Yes, if there was a generic thing to hook any
I'll look into that more closely.
Yes, and having full reference docs could help as well. |
Beta Was this translation helpful? Give feedback.
-
Opened a separate issue #1996 with more details |
Beta Was this translation helpful? Give feedback.
-
Console outputs (or another hermetic-seal-breaking-but-not-really equivalent): very hard agree! I'm trying to debug a universe/aws.cli run that's working locally but failing in GHA, and I'm almost out of ideas for how to surface the underlying AWS response error. As a slight extra ask in the console output space: it'd be great to have a way to unconditionally print some output from a step, regardless of if the DAG failed at that step. My current strategy breaks (I think!) because the |
Beta Was this translation helpful? Give feedback.
-
Context: |
Beta Was this translation helpful? Give feedback.
-
You could also use the local host: client: commands: gitVersion: {
name: "git"
args: ["rev-parse", "--short", "HEAD"]
}
actions: {
build: go.#Build & {
ldflags: "-s -w -X go.dagger.io/dagger/version.Revision=\(client.commands.gitVersion.stdout)"
}
} But this would require git on the host, and I get that it's better to have as much as possible running in a container. To that end, we could have a convenience in #GoBuild & {
source: dagger.#FS
_version: ...
_build: go.#Build & {
"source": source
ldflags: ...
}
} In our case, if it's done only once, I don't feel there's a need to create an abstraction. We do have plans to make fetching the version slightly better (no need for bash): _image: go.#Image // or other image with git
version: docker.#Run & {
input: _image.output
// still need to mount the src
workdir: "/src"
mounts: source: {
dest: "/src"
contents: _source
}
command: {
name: "git"
args: ["rev-parse", "--short", "HEAD"]
}
// less boilerplate to get output (#1620)
stdout: string
}
build: go.#Build & {
source: _source
ldflags: "-s -w -X go.dagger.io/dagger/version.Revision=\(version.stdout)"
} Maybe a version: git.#Run & {
source: _source
command: args: ["rev-parse", "--short", "HEAD"]
stdout: string
}
build: go.#Build & {
source: _source
ldflags: "-s -w -X go.dagger.io/dagger/version.Revision=\(version.stdout)"
} |
Beta Was this translation helpful? Give feedback.
-
Dogfooding notes/wishlist from #1984
/cc @shykes @helderco @samalba
dagger do build lint
(a laMakefile
)dagger do build
should print the revision we just built). I hacked around by writing a file and then removed that line before committing--platform
flag (so we don't need to define the whole CUE DX before making this change)build
andlint
into two different GH jobs because I want to see them separately in the status. However, that doesn't do any good with caching. Ideally the dagger GHA could report individual actions as "statuses" in the PR?docker.#Run
/docker.#Build
experience was a bit challenging: not sure when to use one or the other. On the one hand, I prefer usingdagger.#Build
to define pipelines (e.g. do this, do that, XXX) -- much better than_doA: ... _doB: ...
. On the other hand, I can't do that as soon as I want to export files. I started writingdocker.#Build
steps then had to convert to manual operations (seeactions.version
)docker.#Build
like adagger.#Pipeline
-- I'm not really building anythinggo build -ldflags '-s -w -X go.dagger.io/dagger/version.Revision=$(git rev-parse --short HEAD)
. Mostly because of the point aboveBeta Was this translation helpful? Give feedback.
All reactions