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

Release v0.12.0 alpha.1 #1917

Closed
wants to merge 13 commits into from
Closed

Release v0.12.0 alpha.1 #1917

wants to merge 13 commits into from

Conversation

eysi09
Copy link
Collaborator

@eysi09 eysi09 commented Jun 28, 2020

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

eysi09 and others added 13 commits June 24, 2020 18:49
This greatly expands the power of our template strings. I'll copy the
added docs here for details:

### Nested lookups and maps

In addition to dot-notation for key lookups, we also support bracketed
lookups, e.g. `${some["key"]}` and `${some-array[0]}`.

This style offer nested template resolution, which is quite powerful,
because you can use the output of one expression to choose a key in a
parent expression.

For example, you can declare a mapping variable for your project, and
look up values by another variable such as the current environment name.
To illustrate, here's an excerpt from a project config with a mapping
variable:

```yaml
kind: Project
...
variables:
  - replicas:
      dev: 1
      prod: 3
  ...
```

And here that variable is used in a module:

```yaml
kind: Module
type: container
...
services:
  replicas: ${var.replicas["${environment.name}"]}
  ...
```

When the nested expression is a simple key lookup like above, you can
also just use the nested key directly, e.g.
`${var.replicas[environment.name]}`.

You can even use one variable to index another variable, e.g.
`${var.a[var.b]}`.
This had been bothering me for ages. We now show the available keys
when a key is not found.
Added some debug/silly-level log statements around auth token logic
and `BufferedEventStream`.
We now wait for `BufferedEventStream` to finish flushing any buffered
events and log entries before exiting a command.
…rs (#1910)

* feat(config): allow environment[].variables to reference top-level vars

Also fixes the issue where template strings were resolved in all
environments, instead of just the selected one.

Fixes #1814
This allows projects to define an arbitrary script to run on init.

This is handy for running arbitrary script when initializing.
For example, another provider might declare a dependency on this
provider, to ensure this script runs before resolving that provider.
We now include the log level of streamed log entries sent from
`BufferedEventSream`.
When running without socat we can't wait for socat to start.
I'm not sure how this passed the garden-io CI, it also magically
passed ours when we merged the update to the cli. This is to
quickly unbreak the master branch, I'll investigate further
@eysi09 eysi09 closed this Jun 30, 2020
@thsig thsig deleted the release-v0.12.0-alpha.1 branch August 27, 2020 10:03
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.

4 participants