bake: allow attributes in global scope

[tonistiigi]

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]

@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]

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]

Dependant PRs have been merged.