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

[FEATURE]: Enable the var template key in template strings for variables #2730

Closed
thsig opened this issue Jan 14, 2022 · 7 comments · Fixed by #6814
Closed

[FEATURE]: Enable the var template key in template strings for variables #2730

thsig opened this issue Jan 14, 2022 · 7 comments · Fixed by #6814
Labels
feat/templating Templating in variables and configs feature request

Comments

@thsig
Copy link
Collaborator

thsig commented Jan 14, 2022

Feature Request

Currently, the var/variables template key is not available when resolving template keys in variables. So, for example, something like this is currently not possible:

# project config
...
variables:
  baseDomain: example.com # We want to reuse this prefix
  apiHostname: "api.${var.baseDomain}"
  webhookHostname: "webhooks.${var.baseDomain}"

Supporting this would require us to resolve var references inside variables blocks in dependency order.

Background / Motivation

Supporting this would enable users to further reduce repetition in their configs.

Suggested Implementation(s)

When resolving a variables block (e.g. for the project, or for an environment or module), construct a simple dependency graph of variable references (indexed by the variable key).

Then, resolve the variables in dependency order and incrementally populate the key/value pairs available under the var key and use them to resolve template strings further up the reference graph.

There should also be circular dependency detection with informative error messages.

How important is this feature for you/your team?

🌹 It’s a nice to have, but nice things are nice 🙂

@stale
Copy link

stale bot commented Apr 16, 2022

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

@stale stale bot added the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label Apr 16, 2022
@stale stale bot closed this as completed Apr 30, 2022
@thsig thsig reopened this May 3, 2022
@stale stale bot removed the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label May 3, 2022
@stale
Copy link

stale bot commented Aug 12, 2022

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

@stale stale bot added the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label Aug 12, 2022
@stale stale bot closed this as completed Oct 1, 2022
@vvagaytsev vvagaytsev removed the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label Oct 6, 2022
@vvagaytsev vvagaytsev reopened this Oct 6, 2022
@stale
Copy link

stale bot commented Jan 7, 2023

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

@stale stale bot added the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label Jan 7, 2023
@vvagaytsev vvagaytsev removed the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label Jan 19, 2023
@stale
Copy link

stale bot commented May 21, 2023

This issue has been automatically marked as stale because it hasn't had any activity in 90 days. It will be closed in 14 days if no further activity occurs (e.g. changing labels, comments, commits, etc.). Please feel free to tag a maintainer and ask them to remove the label if you think it doesn't apply. Thank you for submitting this issue and helping make Garden a better product!

@stale stale bot added the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label May 21, 2023
@Orzelius
Copy link
Contributor

@thsig do we still want this?

@stale stale bot removed the stale Label that's automatically set by stalebot. Stale issues get closed after 14 days of inactivity. label May 25, 2023
@vvagaytsev vvagaytsev added feat/templating Templating in variables and configs and removed cli labels Dec 5, 2023
@stefreak
Copy link
Member

This is possible in the next release with #6745

@stefreak
Copy link
Member

stefreak commented Feb 3, 2025

Will be fully resolved in #6814

github-merge-queue bot pushed a commit that referenced this issue Feb 3, 2025
* feat: allow cross-referencing variables in the same scope

Fixes #2730

* feat: allow variable cross-referencing in the project configuration

Avoid resolving variables before creating the variable context;
Otherwise variables cannot reference parent scope and their peers.

* test: add basic test coverage in general and project-level vars

* fix: display resolved variables in `garden get config`

* fix: make sure that variables have access to full context

We need to make sure variables have access to the entire surrounding context, but we also retain fine-grained control over precendence and cross-referencing.

* fix: ensure that higher-precedence variables can refer to root context variables

* test: adapt assertions in project resolve test

* test: add test for action crossreferences

* test: delete unused files

* fix: allow access access to variables with unresolvable $merge when resolving built-in keys like dependencies early

Add an `isFinalContext` flag to `VariablesContext`, encapsulating the behaviour we require where we have to allow access to variables despite a `$merge` operation on the same nesting level cannot be resolved.

We only store resolved variables in `ResolveActionTask`, and rely on the nature of lazy evaluation to fail when we have to.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat/templating Templating in variables and configs feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants