Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bake: allow attributes in global scope #541

Merged
merged 2 commits into from
Mar 27, 2021

Conversation

tonistiigi
Copy link
Member

depends on #539 #538

I propose this as a base for #489 (review)

You can now define global scope attributes in HCL/JSON and use them for code reuse and setting values for variables. This means you can do a "data-only" HCL file with the values you want to set/override and use it in the list of regular output files.

Eg.

variable "REPO" {
  default = "tonistiigi/repo"
}

APP_TAG="foo"

target "app" {
  tags = ["${REPO}/${APP_TAG}"]
  args = {
     variant = APP_TAG
  }
}

You can use this file directly or create an override configuration file

WHOAMI="myuser"
REPO="${WHOAMI}/foo"
APP_TAG="bar-by-${WHOAMI}"

and invoke bake together with both of the files.

So instead of loading a .env automatically with another custom format, you can just pass any config file. The HCL attributes are not 100% compatible with env file format so I think for compose support we still should have a fallback, and maybe still automatically load it if you parse compose. Possibly we can just use the new compose library that does that automatically on parsing compose. For everything else, you can use HCL/JSON attributes.

In addition to strings HCL file attributes also support custom data types: arrays, booleans etc. You can refer to other attributes or call built-in functions(user functions not supported atm).

The difference between variables and attributes is that only variables are configurable by the user on invocation. I think this distinction is important, for example in the future I would expect that we add a "description" property to variables so we can show the user what variables are accepted and what do they mean.

I think we should also do #445

@crazy-max @tiborvass @thaJeztah @vanstee

@crazy-max
Copy link
Member

@tonistiigi

So instead of loading a .env automatically with another custom format, you can just pass any config file. The HCL attributes are not 100% compatible with env file format so I think for compose support we still should have a fallback, and maybe still automatically load it if you parse compose. Possibly we can just use the new compose library that does that automatically on parsing compose. For everything else, you can use HCL/JSON attributes.

Indeed, I think it is a better approach compared to what I proposed in #489 and also more intuitive for the HCL format.

In addition to strings HCL file attributes also support custom data types: arrays, booleans etc. You can refer to other attributes or call built-in functions(user functions not supported atm).

About that I think something like I suggested in #491 (comment) for value types accepted for a variable like Terraform does would be nice. But that could be done in a further PR.

@tonistiigi
Copy link
Member Author

About that I think something like I suggested in #491 (comment) for value types accepted for a variable like Terraform does would be nice. But that could be done in a further PR.

Yes, validation would be nice (in follow-up). For type, I just detect it from the default value atm. but that gets tricky with list types. Maybe for lists, you would need to define it.

@tonistiigi tonistiigi force-pushed the json-vars-attrs branch 2 times, most recently from b9f5558 to 3193264 Compare March 8, 2021 05:28
@tonistiigi tonistiigi marked this pull request as ready for review March 23, 2021 16:02
@tonistiigi
Copy link
Member Author

Dependant PRs have been merged.

Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants