Conversation
crazy-max
force-pushed
the
build-inputs
branch
9 times, most recently
from
65a88d8 to
ee9ed7a
Compare
|
Yes @crazy-max would be great to keep examples here until we have something on docs.docker.com |
crazy-max
force-pushed
the
build-inputs
branch
3 times, most recently
from
c13ca88 to
e9c5806
Compare
|
@tonistiigi Pushed extra commit to remove GHA cache for now related to #56 |
crazy-max
force-pushed
the
build-inputs
branch
2 times, most recently
from
bb98b55 to
d99e23b
Compare
crazy-max
force-pushed
the
build-inputs
branch
from
d99e23b to
f432c1b
Compare
.github/workflows/build.yml
Outdated
| envs: | ||
| type: string | ||
| description: "Which scope cache object belongs to if cache enabled (defaults to target name if set)" | ||
| description: "Environment variables to inject in the reusable workflow as list of key-value pair. This is similar to the GitHub Actions env context but as it cannot be used when calling a reusable workflow, we need to define our own input" |
There was a problem hiding this comment.
For build or bake, people might want to pass environment variables to the workflow for build-args with build or more importantly for bake to solve variables in the bake definition like: https://github.com/moby/buildkit/pull/6388/files#diff-edc3cacddc1f4df8e0e08c34f870525dffdf521312794ee0f1bccd1638534385R245-R248
There was a problem hiding this comment.
After offline discussion let's remove this input. User can either use build-args or bake override.
| description: "List of build-time variables. If you want to set a build-arg through an environment variable, use the envs input" | ||
| required: false | ||
| meta-tags: | ||
| context: |
There was a problem hiding this comment.
Do we validate that this can only be subpath for now? Should we call something like subpath.
I think we could be open to supporting external repositories here in the future but it should be create from the validation side that these would require a different kind of policy rules.
There was a problem hiding this comment.
Do we validate that this can only be subpath for now? Should we call something like
subpath.
Yes for build or bake this can only be a subdir of the Git context (defaults to .):
- https://github.com/docker/github-builder-experimental/blob/4358d190e83cdc7b9e1f2807bd00e6fb2f0a878d/.github/workflows/build.yml#L349-L350
- https://github.com/docker/github-builder-experimental/blob/4358d190e83cdc7b9e1f2807bd00e6fb2f0a878d/.github/workflows/bake.yml#L221-L224
I think we could be open to supporting external repositories here in the future but it should be create from the validation side that these would require a different kind of policy rules.
I see yeah that makes sense
.github/workflows/build.yml
Outdated
| description: "Raw authentication to registries, defined as YAML objects (for image output)" | ||
| required: false | ||
| github-token: | ||
| description: "GitHub Token used to authenticate against a repository for Git context" |
There was a problem hiding this comment.
So this is for external Git repositories?
There was a problem hiding this comment.
Not for external Git repos, we need to be able to fetch private repos which requires the GitHub Token set and used via GIT_AUTH_TOKEN:
- https://github.com/docker/github-builder-experimental/blob/4358d190e83cdc7b9e1f2807bd00e6fb2f0a878d/.github/workflows/build.yml#L422
- https://github.com/docker/github-builder-experimental/blob/4358d190e83cdc7b9e1f2807bd00e6fb2f0a878d/.github/workflows/bake.yml#L513
Similar to what build-push-action and bake-action do today for Git context
crazy-max
force-pushed
the
build-inputs
branch
3 times, most recently
from
537c77b to
e7da8ba
Compare
crazy-max
force-pushed
the
build-inputs
branch
3 times, most recently
from
b9b7b8c to
f37af04
Compare
| The [`build.yml` reusable workflow](.github/workflows/build.yml) lets you build | ||
| container images and artifacts from a Dockerfile with a user experience similar | ||
| to [`docker/build-push-action`](https://github.com/docker/build-push-action/). | ||
| It provides a Docker-maintained, opinionated build pipeline that applies best | ||
| practices for security, performance, and reliability by default, including | ||
| isolated execution and signed SLSA provenanc while keeping per-repository | ||
| configuration minimal. |
There was a problem hiding this comment.
Can we add a similar but shorter note under the bake section to call out that it's a replacement for / composite of the docker/bake-action + ancillary support actions.
crazy-max
force-pushed
the
build-inputs
branch
from
f37af04 to
94a49a8
Compare
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
crazy-max
force-pushed
the
build-inputs
branch
from
94a49a8 to
7eeaea0
Compare
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
Signed-off-by: CrazyMax <[email protected]>
crazy-max
force-pushed
the
build-inputs
branch
from
f7e8450 to
6e46b8d
Compare
3 participants
relates to docker/buildx#3520 (review) and internal discussions.
Refactor the inputs for our workflows to be more consistent with our upstream actions and also avoid confusion like docker/buildx#3520 (review).