ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/config/interpolate_funcs_test.go

1085 lines
18 KiB
Go
Raw Normal View History

config: lookup function works + tests
2014-07-21 22:12:43 +02:00
package config
import (
config: add join() function
2014-10-10 06:22:35 +02:00
"fmt"
config: add file() function for reading file contents
2014-07-23 03:35:36 +02:00
"io/ioutil"
"os"
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
"reflect"
config: lookup function works + tests
2014-07-21 22:12:43 +02:00
"testing"
config: add `concat` function [GH-191]
2014-08-19 22:14:45 +02:00
remove config/lang, use hashicorp/hil
2016-01-31 08:38:37 +01:00
"github.com/hashicorp/hil"
"github.com/hashicorp/hil/ast"
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
)
config: add `concat` function [GH-191]
2014-08-19 22:14:45 +02:00
Test cases for compact()
2015-09-15 15:50:31 +02:00
func TestInterpolateFuncCompact(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// empty string within array
{
Use {a,b} instead of {b,c} How does the alphabet even?
2015-09-16 11:09:34 +02:00
`${compact(split(",", "a,,b"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b"},
Test cases for compact()
2015-09-15 15:50:31 +02:00
false,
},
// empty string at the end of array
{
Use {a,b} instead of {b,c} How does the alphabet even?
2015-09-16 11:09:34 +02:00
`${compact(split(",", "a,b,"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b"},
Test cases for compact()
2015-09-15 15:50:31 +02:00
false,
},
// single empty string
{
`${compact(split(",", ""))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{},
Test cases for compact()
2015-09-15 15:50:31 +02:00
false,
},
},
})
}
Various interpolation functions for CIDR range manipulation. These new functions allow Terraform to be used for network address space planning tasks, and make it easier to produce reusable modules that contain or depend on network infrastructure. For example: - cidrsubnet allows an aws_subnet to derive its CIDR prefix from its parent aws_vpc. - cidrhost allows a fixed IP address for a resource to be assigned within an address range defined elsewhere. - cidrnetmask provides the dotted-decimal form of a prefix length that is accepted by some systems such as routing tables and static network interface configuration files. The bulk of the work here is done by an external library I authored called go-cidr. It is MIT licensed and was implemented primarily for the purpose of using it within Terraform. It has its own unit tests and so the unit tests within this change focus on simple success cases and on the correct handling of the various error cases.
2015-10-22 17:10:42 +02:00
func TestInterpolateFuncCidrHost(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${cidrhost("192.168.1.0/24", 5)}`,
"192.168.1.5",
false,
},
{
`${cidrhost("192.168.1.0/30", 255)}`,
nil,
true, // 255 doesn't fit in two bits
},
{
`${cidrhost("not-a-cidr", 6)}`,
nil,
true, // not a valid CIDR mask
},
{
`${cidrhost("10.256.0.0/8", 6)}`,
nil,
true, // can't have an octet >255
},
},
})
}
func TestInterpolateFuncCidrNetmask(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${cidrnetmask("192.168.1.0/24")}`,
"255.255.255.0",
false,
},
{
`${cidrnetmask("192.168.1.0/32")}`,
"255.255.255.255",
false,
},
{
`${cidrnetmask("0.0.0.0/0")}`,
"0.0.0.0",
false,
},
{
// This doesn't really make sense for IPv6 networks
// but it ought to do something sensible anyway.
`${cidrnetmask("1::/64")}`,
"ffff:ffff:ffff:ffff::",
false,
},
{
`${cidrnetmask("not-a-cidr")}`,
nil,
true, // not a valid CIDR mask
},
{
`${cidrnetmask("10.256.0.0/8")}`,
nil,
true, // can't have an octet >255
},
},
})
}
func TestInterpolateFuncCidrSubnet(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${cidrsubnet("192.168.2.0/20", 4, 6)}`,
"192.168.6.0/24",
false,
},
{
`${cidrsubnet("fe80::/48", 16, 6)}`,
"fe80:0:0:6::/64",
false,
},
{
// IPv4 address encoded in IPv6 syntax gets normalized
`${cidrsubnet("::ffff:192.168.0.0/112", 8, 6)}`,
"192.168.6.0/24",
false,
},
{
`${cidrsubnet("192.168.0.0/30", 4, 6)}`,
nil,
true, // not enough bits left
},
{
`${cidrsubnet("192.168.0.0/16", 2, 16)}`,
nil,
true, // can't encode 16 in 2 bits
},
{
`${cidrsubnet("not-a-cidr", 4, 6)}`,
nil,
true, // not a valid CIDR mask
},
{
`${cidrsubnet("10.256.0.0/8", 4, 6)}`,
nil,
true, // can't have an octet >255
},
},
})
}
Add coalesce func
2015-11-08 07:34:56 +01:00
func TestInterpolateFuncCoalesce(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${coalesce("first", "second", "third")}`,
"first",
false,
},
{
`${coalesce("", "second", "third")}`,
"second",
false,
},
{
`${coalesce("", "", "")}`,
"",
false,
},
{
`${coalesce("foo")}`,
nil,
true,
},
},
})
}
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
func TestInterpolateFuncConcat(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// String + list
{
`${concat("a", split(",", "b,c"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b", "c"},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
// List + string
{
`${concat(split(",", "a,b"), "c")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b", "c"},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
// Single list
{
`${concat(split(",", ",foo,"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"", "foo", ""},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
{
`${concat(split(",", "a,b,c"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b", "c"},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
// Two lists
{
`${concat(split(",", "a,b,c"), split(",", "d,e"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b", "c", "d", "e"},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
// Two lists with different separators
{
`${concat(split(",", "a,b,c"), split(" ", "d e"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b", "c", "d", "e"},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
// More lists
{
`${concat(split(",", "a,b"), split(",", "c,d"), split(",", "e,f"), split(",", "0,1"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"a", "b", "c", "d", "e", "f", "0", "1"},
config: concat function supports lists (combines more lists into one)
2015-05-03 16:53:33 +02:00
false,
},
},
})
}
config: add file() function for reading file contents
2014-07-23 03:35:36 +02:00
func TestInterpolateFuncFile(t *testing.T) {
tf, err := ioutil.TempFile("", "tf")
if err != nil {
t.Fatalf("err: %s", err)
}
path := tf.Name()
tf.Write([]byte("foo"))
tf.Close()
defer os.Remove(path)
config: add lookup function back
2015-01-13 21:06:04 +01:00
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
fmt.Sprintf(`${file("%s")}`, path),
"foo",
false,
},
config: add file() function for reading file contents
2014-07-23 03:35:36 +02:00
config: add lookup function back
2015-01-13 21:06:04 +01:00
// Invalid path
{
`${file("/i/dont/exist")}`,
nil,
true,
},
config: add file() function for reading file contents
2014-07-23 03:35:36 +02:00
config: add lookup function back
2015-01-13 21:06:04 +01:00
// Too many args
{
`${file("foo", "bar")}`,
nil,
true,
},
config: add file() function for reading file contents
2014-07-23 03:35:36 +02:00
},
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
})
config: add file() function for reading file contents
2014-07-23 03:35:36 +02:00
}
config: fmt
2014-07-23 03:35:53 +02:00
config: add format function
2015-03-02 19:26:06 +01:00
func TestInterpolateFuncFormat(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${format("hello")}`,
"hello",
false,
},
{
`${format("hello %s", "world")}`,
"hello world",
false,
},
{
`${format("hello %d", 42)}`,
"hello 42",
false,
},
{
`${format("hello %05d", 42)}`,
"hello 00042",
false,
},
{
`${format("hello %05d", 12345)}`,
"hello 12345",
false,
},
},
})
}
config: add formatlist formatlist distributes formatting over lists. See the docs for details. As a colleague commented: "It happens all the time that we want a set of outputs, but in a slightly different way than just simple joining or concatting." formatlist (combined with join) makes it easy to satisfy those needs.
2015-05-06 05:34:40 +02:00
func TestInterpolateFuncFormatList(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// formatlist requires at least one list
{
`${formatlist("hello")}`,
nil,
true,
},
{
`${formatlist("hello %s", "world")}`,
nil,
true,
},
// formatlist applies to each list element in turn
{
`${formatlist("<%s>", split(",", "A,B"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"<A>", "<B>"},
config: add formatlist formatlist distributes formatting over lists. See the docs for details. As a colleague commented: "It happens all the time that we want a set of outputs, but in a slightly different way than just simple joining or concatting." formatlist (combined with join) makes it easy to satisfy those needs.
2015-05-06 05:34:40 +02:00
false,
},
// formatlist repeats scalar elements
{
`${join(", ", formatlist("%s=%s", "x", split(",", "A,B,C")))}`,
"x=A, x=B, x=C",
false,
},
// Multiple lists are walked in parallel
{
`${join(", ", formatlist("%s=%s", split(",", "A,B,C"), split(",", "1,2,3")))}`,
"A=1, B=2, C=3",
false,
},
// Mismatched list lengths generate an error
{
`${formatlist("%s=%2s", split(",", "A,B,C,D"), split(",", "1,2,3"))}`,
nil,
true,
},
config: make formatlist work on lists of length 1 removes treat-lists-as-scalar special casing for formatlist /cc @radeksimko fixes #2240
2015-06-26 01:45:17 +02:00
// Works with lists of length 1 [GH-2240]
{
`${formatlist("%s.id", split(",", "demo-rest-elb"))}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"demo-rest-elb.id"},
config: make formatlist work on lists of length 1 removes treat-lists-as-scalar special casing for formatlist /cc @radeksimko fixes #2240
2015-06-26 01:45:17 +02:00
false,
},
config: add formatlist formatlist distributes formatting over lists. See the docs for details. As a colleague commented: "It happens all the time that we want a set of outputs, but in a slightly different way than just simple joining or concatting." formatlist (combined with join) makes it easy to satisfy those needs.
2015-05-06 05:34:40 +02:00
},
})
}
Add a function to find the index of an element in a list.
2015-07-12 21:55:19 +02:00
func TestInterpolateFuncIndex(t *testing.T) {
testFunction(t, testFunctionConfig{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
Vars: map[string]ast.Variable{
"var.list1": interfaceToVariableSwallowError([]string{"notfoo", "stillnotfoo", "bar"}),
"var.list2": interfaceToVariableSwallowError([]string{"foo"}),
"var.list3": interfaceToVariableSwallowError([]string{"foo", "spam", "bar", "eggs"}),
},
Add a function to find the index of an element in a list.
2015-07-12 21:55:19 +02:00
Cases: []testFunctionCase{
{
`${index("test", "")}`,
nil,
true,
},
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${index(var.list1, "foo")}`,
Add a function to find the index of an element in a list.
2015-07-12 21:55:19 +02:00
nil,
true,
},
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${index(var.list2, "foo")}`,
Add a function to find the index of an element in a list.
2015-07-12 21:55:19 +02:00
"0",
false,
},
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${index(var.list3, "bar")}`,
Add a function to find the index of an element in a list.
2015-07-12 21:55:19 +02:00
"2",
false,
},
},
})
}
config: add join() function
2014-10-10 06:22:35 +02:00
func TestInterpolateFuncJoin(t *testing.T) {
config: add lookup function back
2015-01-13 21:06:04 +01:00
testFunction(t, testFunctionConfig{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
Vars: map[string]ast.Variable{
"var.a_list": interfaceToVariableSwallowError([]string{"foo"}),
"var.a_longer_list": interfaceToVariableSwallowError([]string{"foo", "bar", "baz"}),
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
Cases: []testFunctionCase{
{
`${join(",")}`,
nil,
true,
},
config: add join() function
2014-10-10 06:22:35 +02:00
config: add lookup function back
2015-01-13 21:06:04 +01:00
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${join(",", var.a_list)}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
"foo",
false,
},
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${join(".", var.a_longer_list)}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
"foo.bar.baz",
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
false,
},
config: add join() function
2014-10-10 06:22:35 +02:00
},
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
})
config: add join() function
2014-10-10 06:22:35 +02:00
}
config: new interpolation function jsonencode
2016-03-29 03:02:06 +02:00
func TestInterpolateFuncJSONEncode(t *testing.T) {
testFunction(t, testFunctionConfig{
Vars: map[string]ast.Variable{
"easy": ast.Variable{
Value: "test",
Type: ast.TypeString,
},
"hard": ast.Variable{
Value: " foo \\ \n \t \" bar ",
Type: ast.TypeString,
},
config: support lists and maps in jsonencode For now we only support lists and maps whose values are strings, not deeply nested data.
2016-05-18 19:45:22 +02:00
"list": interfaceToVariableSwallowError([]string{"foo", "bar\tbaz"}),
// XXX can't use InterfaceToVariable as it converts empty slice into empty
// map.
"emptylist": ast.Variable{
Value: []ast.Variable{},
Type: ast.TypeList,
},
"map": interfaceToVariableSwallowError(map[string]string{
"foo": "bar",
"ba \n z": "q\\x",
}),
"emptymap": interfaceToVariableSwallowError(map[string]string{}),
// Not yet supported (but it would be nice)
"nestedlist": interfaceToVariableSwallowError([][]string{{"foo"}}),
"nestedmap": interfaceToVariableSwallowError(map[string][]string{"foo": {"bar"}}),
config: new interpolation function jsonencode
2016-03-29 03:02:06 +02:00
},
Cases: []testFunctionCase{
{
`${jsonencode("test")}`,
`"test"`,
false,
},
{
`${jsonencode(easy)}`,
`"test"`,
false,
},
{
`${jsonencode(hard)}`,
`" foo \\ \n \t \" bar "`,
false,
},
{
`${jsonencode("")}`,
`""`,
false,
},
{
`${jsonencode()}`,
nil,
true,
},
config: support lists and maps in jsonencode For now we only support lists and maps whose values are strings, not deeply nested data.
2016-05-18 19:45:22 +02:00
{
`${jsonencode(list)}`,
`["foo","bar\tbaz"]`,
false,
},
{
`${jsonencode(emptylist)}`,
`[]`,
false,
},
{
`${jsonencode(map)}`,
`{"ba \n z":"q\\x","foo":"bar"}`,
false,
},
{
`${jsonencode(emptymap)}`,
`{}`,
false,
},
{
`${jsonencode(nestedlist)}`,
nil,
true,
},
{
`${jsonencode(nestedmap)}`,
nil,
true,
},
config: new interpolation function jsonencode
2016-03-29 03:02:06 +02:00
},
})
}
config: add replace function
2015-03-02 18:37:40 +01:00
func TestInterpolateFuncReplace(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// Regular search and replace
{
`${replace("hello", "hel", "bel")}`,
"bello",
false,
},
// Search string doesn't match
{
`${replace("hello", "nope", "bel")}`,
"hello",
false,
},
// Regular expression
{
`${replace("hello", "/l/", "L")}`,
"heLLo",
false,
},
{
`${replace("helo", "/(l)/", "$1$1")}`,
"hello",
false,
},
config: test bad regexp for replace
2015-03-02 18:44:45 +01:00
// Bad regexp
{
`${replace("helo", "/(l/", "$1$1")}`,
nil,
true,
},
config: add replace function
2015-03-02 18:37:40 +01:00
},
})
}
length added to built-in functions
2015-04-12 16:17:26 +02:00
func TestInterpolateFuncLength(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// Raw strings
{
`${length("")}`,
"0",
false,
},
{
`${length("a")}`,
"1",
false,
},
{
`${length(" ")}`,
"1",
false,
},
{
`${length(" a ,")}`,
"4",
false,
},
{
`${length("aaa")}`,
"3",
false,
},
// Lists
{
`${length(split(",", "a"))}`,
"1",
false,
},
{
`${length(split(",", "foo,"))}`,
"2",
false,
},
{
`${length(split(",", ",foo,"))}`,
"3",
false,
},
{
`${length(split(",", "foo,bar"))}`,
"2",
false,
},
{
`${length(split(".", "one.two.three.four.five"))}`,
"5",
false,
},
Add an explicit test for PR #2973
2015-10-25 19:55:21 +01:00
// Want length 0 if we split an empty string then compact
{
`${length(compact(split(",", "")))}`,
"0",
false,
},
length added to built-in functions
2015-04-12 16:17:26 +02:00
},
})
}
Add signum interpolation function This function returns -1 for negative numbers, 0 for 0 and 1 for positive numbers. Useful when you need to set a value for the first resource and a different value for the rest of the resources. Example: `${element(split(",", var.r53_failover_policy), signum(count.index))}`
2016-01-27 16:36:31 +01:00
func TestInterpolateFuncSignum(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${signum()}`,
nil,
true,
},
{
`${signum("")}`,
nil,
true,
},
{
`${signum(0)}`,
"0",
false,
},
{
`${signum(15)}`,
"1",
false,
},
{
`${signum(-29)}`,
"-1",
false,
},
},
})
}
Add split function
2015-01-28 22:59:16 +01:00
func TestInterpolateFuncSplit(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${split(",")}`,
nil,
true,
},
core: allow distinguishing between empty lists and strings Had to handle a lot of implicit leaning on a few properties of the old representation: * Old representation allowed plain strings to be treated as lists without problem (i.e. shoved into strings.Split), now strings need to be checked whether they are a list before they are treated as one (i.e. shoved into StringList(s).Slice()). * Tested behavior of 0 and 1 length lists in formatlist() was a side effect of the representation. Needs to be special cased now to maintain the behavior. * Found a pretty old context test failure that was wrong in several different ways. It's covered by TestContext2Apply_multiVar so I removed it.
2015-06-26 00:55:51 +02:00
{
`${split(",", "")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{""},
core: allow distinguishing between empty lists and strings Had to handle a lot of implicit leaning on a few properties of the old representation: * Old representation allowed plain strings to be treated as lists without problem (i.e. shoved into strings.Split), now strings need to be checked whether they are a list before they are treated as one (i.e. shoved into StringList(s).Slice()). * Tested behavior of 0 and 1 length lists in formatlist() was a side effect of the representation. Needs to be special cased now to maintain the behavior. * Found a pretty old context test failure that was wrong in several different ways. It's covered by TestContext2Apply_multiVar so I removed it.
2015-06-26 00:55:51 +02:00
false,
},
Add split function
2015-01-28 22:59:16 +01:00
{
`${split(",", "foo")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"foo"},
Add split function
2015-01-28 22:59:16 +01:00
false,
},
length added to built-in functions
2015-04-12 16:17:26 +02:00
{
`${split(",", ",,,")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"", "", "", ""},
length added to built-in functions
2015-04-12 16:17:26 +02:00
false,
},
{
`${split(",", "foo,")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"foo", ""},
length added to built-in functions
2015-04-12 16:17:26 +02:00
false,
},
{
`${split(",", ",foo,")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"", "foo", ""},
length added to built-in functions
2015-04-12 16:17:26 +02:00
false,
},
Add split function
2015-01-28 22:59:16 +01:00
{
`${split(".", "foo.bar.baz")}`,
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
[]interface{}{"foo", "bar", "baz"},
Add split function
2015-01-28 22:59:16 +01:00
false,
},
},
})
}
config: lookup function works + tests
2014-07-21 22:12:43 +02:00
func TestInterpolateFuncLookup(t *testing.T) {
config: add lookup function back
2015-01-13 21:06:04 +01:00
testFunction(t, testFunctionConfig{
config: use new API
2015-01-15 07:01:42 +01:00
Vars: map[string]ast.Variable{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
"var.foo": ast.Variable{
Type: ast.TypeMap,
Value: map[string]ast.Variable{
"bar": ast.Variable{
Type: ast.TypeString,
Value: "baz",
},
},
config: variables must be typed
2015-01-14 19:40:43 +01:00
},
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
Cases: []testFunctionCase{
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${lookup(var.foo, "bar")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
"baz",
false,
config: lookup function works + tests
2014-07-21 22:12:43 +02:00
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
// Invalid key
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${lookup(var.foo, "baz")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
nil,
true,
config: lookup function works + tests
2014-07-21 22:12:43 +02:00
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
// Too many args
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${lookup(var.foo, "bar", "baz")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
nil,
true,
config: lookup function works + tests
2014-07-21 22:12:43 +02:00
},
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
})
config: lookup function works + tests
2014-07-21 22:12:43 +02:00
}
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
func TestInterpolateFuncKeys(t *testing.T) {
testFunction(t, testFunctionConfig{
Vars: map[string]ast.Variable{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
"var.foo": ast.Variable{
Type: ast.TypeMap,
Value: map[string]ast.Variable{
"bar": ast.Variable{
Value: "baz",
Type: ast.TypeString,
},
"qux": ast.Variable{
Value: "quack",
Type: ast.TypeString,
},
},
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
},
"var.str": ast.Variable{
Value: "astring",
Type: ast.TypeString,
},
},
Cases: []testFunctionCase{
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${keys(var.foo)}`,
[]interface{}{"bar", "qux"},
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
false,
},
// Invalid key
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${keys(var.not)}`,
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
nil,
true,
},
// Too many args
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${keys(var.foo, "bar")}`,
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
nil,
true,
},
// Not a map
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${keys(var.str)}`,
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
nil,
true,
},
},
})
}
func TestInterpolateFuncValues(t *testing.T) {
testFunction(t, testFunctionConfig{
Vars: map[string]ast.Variable{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
"var.foo": ast.Variable{
Type: ast.TypeMap,
Value: map[string]ast.Variable{
"bar": ast.Variable{
Value: "quack",
Type: ast.TypeString,
},
"qux": ast.Variable{
Value: "baz",
Type: ast.TypeString,
},
},
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
},
"var.str": ast.Variable{
Value: "astring",
Type: ast.TypeString,
},
},
Cases: []testFunctionCase{
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${values(var.foo)}`,
[]interface{}{"quack", "baz"},
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
false,
},
// Invalid key
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${values(var.not)}`,
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
nil,
true,
},
// Too many args
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${values(var.foo, "bar")}`,
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
nil,
true,
},
// Not a map
{
core: Use native HIL maps instead of flatmaps This changes the representation of maps in the interpolator from the dotted flatmap form of a string variable named "var.variablename.key" per map element to use native HIL maps instead. This involves porting some of the interpolation functions in order to keep the tests green, and adding support for map outputs. There is one backwards incompatibility: as a result of an implementation detail of maps, one could access an indexed map variable using the syntax "${var.variablename.key}". This is no longer possible - instead HIL native syntax - "${var.variablename["key"]}" must be used. This was previously documented, (though not heavily used) so it must be noted as a backward compatibility issue for Terraform 0.7.
2016-04-11 19:40:06 +02:00
`${values(var.str)}`,
core: keys() and values() funcs for map variables they work on maps with both keys and values that are string types, which AFAICT are the only types of maps we have right now. closes #1915
2015-06-02 23:48:38 +02:00
nil,
true,
},
},
})
}
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
func interfaceToVariableSwallowError(input interface{}) ast.Variable {
variable, _ := hil.InterfaceToVariable(input)
return variable
}
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
func TestInterpolateFuncElement(t *testing.T) {
config: add lookup function back
2015-01-13 21:06:04 +01:00
testFunction(t, testFunctionConfig{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
Vars: map[string]ast.Variable{
"var.a_list": interfaceToVariableSwallowError([]string{"foo", "baz"}),
"var.a_short_list": interfaceToVariableSwallowError([]string{"foo"}),
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
Cases: []testFunctionCase{
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${element(var.a_list, "1")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
"baz",
false,
},
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
config: add lookup function back
2015-01-13 21:06:04 +01:00
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${element(var.a_short_list, "0")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
"foo",
false,
},
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
config: add lookup function back
2015-01-13 21:06:04 +01:00
// Invalid index should wrap vs. out-of-bounds
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${element(var.a_list, "2")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
"foo",
false,
},
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
Error out on negative indices in element()
2016-02-22 23:47:17 +01:00
// Negative number should fail
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${element(var.a_short_list, "-1")}`,
Error out on negative indices in element()
2016-02-22 23:47:17 +01:00
nil,
true,
},
config: add lookup function back
2015-01-13 21:06:04 +01:00
// Too many args
{
core: support native list variables in config This commit adds support for native list variables and outputs, building up on the previous change to state. Interpolation functions now return native lists in preference to StringList. List variables are defined like this: variable "test" { # This can also be inferred type = "list" default = ["Hello", "World"] } output "test_out" { value = "${var.a_list}" } This results in the following state: ``` ... "outputs": { "test_out": [ "hello", "world" ] }, ... ``` And the result of terraform output is as follows: ``` $ terraform output test_out = [ hello world ] ``` Using the output name, an xargs-friendly representation is output: ``` $ terraform output test_out hello world ``` The output command also supports indexing into the list (with appropriate range checking and no wrapping): ``` $ terraform output test_out 1 world ``` Along with maps, list outputs from one module may be passed as variables into another, removing the need for the `join(",", var.list_as_string)` and `split(",", var.list_as_string)` which was previously necessary in Terraform configuration. This commit also updates the tests and implementations of built-in interpolation functions to take and return native lists where appropriate. A backwards compatibility note: previously the concat interpolation function was capable of concatenating either strings or lists. The strings use case was deprectated a long time ago but still remained. Because we cannot return `ast.TypeAny` from an interpolation function, this use case is no longer supported for strings - `concat` is only capable of concatenating lists. This should not be a huge issue - the type checker picks up incorrect parameters, and the native HIL string concatenation - or the `join` function - can be used to replicate the missing behaviour.
2016-04-22 02:03:24 +02:00
`${element(var.a_list, "0", "2")}`,
config: add lookup function back
2015-01-13 21:06:04 +01:00
nil,
true,
},
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
},
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
})
}
implements base64{enc,dec} interpolation funcs fixes #3320 Signed-off-by: Gorka Lerchundi Osa <glertxundi@gmail.com>
2015-09-25 09:23:36 +02:00
func TestInterpolateFuncBase64Encode(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// Regular base64 encoding
{
Rename base64enc/dec to encode/decode. There isn't any precedent for abbreviating words in the interpolation function names, and it may not be clear to all users what "enc" and "dec" are short for, so instead we'll prefer to spell out the whole words for improved readability.
2015-10-04 00:12:51 +02:00
`${base64encode("abc123!?$*&()'-=@~")}`,
implements base64{enc,dec} interpolation funcs fixes #3320 Signed-off-by: Gorka Lerchundi Osa <glertxundi@gmail.com>
2015-09-25 09:23:36 +02:00
"YWJjMTIzIT8kKiYoKSctPUB+",
false,
},
},
})
}
func TestInterpolateFuncBase64Decode(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
// Regular base64 decoding
{
Rename base64enc/dec to encode/decode. There isn't any precedent for abbreviating words in the interpolation function names, and it may not be clear to all users what "enc" and "dec" are short for, so instead we'll prefer to spell out the whole words for improved readability.
2015-10-04 00:12:51 +02:00
`${base64decode("YWJjMTIzIT8kKiYoKSctPUB+")}`,
implements base64{enc,dec} interpolation funcs fixes #3320 Signed-off-by: Gorka Lerchundi Osa <glertxundi@gmail.com>
2015-09-25 09:23:36 +02:00
"abc123!?$*&()'-=@~",
false,
},
// Invalid base64 data decoding
{
Rename base64enc/dec to encode/decode. There isn't any precedent for abbreviating words in the interpolation function names, and it may not be clear to all users what "enc" and "dec" are short for, so instead we'll prefer to spell out the whole words for improved readability.
2015-10-04 00:12:51 +02:00
`${base64decode("this-is-an-invalid-base64-data")}`,
implements base64{enc,dec} interpolation funcs fixes #3320 Signed-off-by: Gorka Lerchundi Osa <glertxundi@gmail.com>
2015-09-25 09:23:36 +02:00
nil,
true,
},
},
})
}
Add lower / upper interpolation functions
2015-10-20 03:49:51 +02:00
func TestInterpolateFuncLower(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${lower("HELLO")}`,
"hello",
false,
},
{
`${lower("")}`,
"",
false,
},
{
`${lower()}`,
nil,
true,
},
},
})
}
func TestInterpolateFuncUpper(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${upper("hello")}`,
"HELLO",
false,
},
{
`${upper("")}`,
"",
false,
},
{
`${upper()}`,
nil,
true,
},
},
})
}
add sha1 interpolation
2015-12-27 23:28:56 +01:00
func TestInterpolateFuncSha1(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${sha1("test")}`,
"a94a8fe5ccb19ba61c4c0873d391e987982fbbd3",
false,
},
},
})
}
Add a sha256(...) interpolation function.
2016-01-17 00:54:04 +01:00
func TestInterpolateFuncSha256(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
config: Add base64sha256() function
2016-01-29 13:09:57 +01:00
{ // hexadecimal representation of sha256 sum
Add a sha256(...) interpolation function.
2016-01-17 00:54:04 +01:00
`${sha256("test")}`,
"9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
false,
},
},
})
}
Update the test file
2016-01-30 10:52:45 +01:00
func TestInterpolateFuncTrimSpace(t *testing.T) {
Add the trim() interpolation function
2016-01-30 00:28:04 +01:00
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
Update the test file
2016-01-30 10:52:45 +01:00
`${trimspace(" test ")}`,
Add the trim() interpolation function
2016-01-30 00:28:04 +01:00
"test",
false,
},
},
})
}
config: Add base64sha256() function
2016-01-29 13:09:57 +01:00
func TestInterpolateFuncBase64Sha256(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${base64sha256("test")}`,
"n4bQgYhMfWWaL+qgxVrQFaO/TxsrC4Is0V1sFbDwCgg=",
false,
},
{ // This will differ because we're base64-encoding hex represantiation, not raw bytes
`${base64encode(sha256("test"))}`,
"OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTViMGYwMGEwOA==",
false,
},
},
})
}
config: Add new interpolation function - md5
2016-02-23 12:29:11 +01:00
func TestInterpolateFuncMd5(t *testing.T) {
testFunction(t, testFunctionConfig{
Cases: []testFunctionCase{
{
`${md5("tada")}`,
"ce47d07243bb6eaf5e1322c81baf9bbf",
false,
},
{ // Confirm that we're not trimming any whitespaces
`${md5(" tada ")}`,
"aadf191a583e53062de2d02c008141c4",
false,
},
{ // We accept empty string too
`${md5("")}`,
"d41d8cd98f00b204e9800998ecf8427e",
false,
},
},
})
}
Revert "Revert "core: Add uuid() interpolate function."" This reverts commit 661be01d9b11736ab87d95da1901ca2c8518faac.
2016-03-21 21:14:30 +01:00
func TestInterpolateFuncUUID(t *testing.T) {
results := make(map[string]bool)
for i := 0; i < 100; i++ {
ast, err := hil.Parse("${uuid()}")
if err != nil {
t.Fatalf("err: %s", err)
}
deps: Update call sites of hil.Eval from update hil.Eval() now returns (hil.EvaluationResult, error) instead of (value, type, error). This commit updates the call sites, but retains all previous behaviour. Tests are also updated.
2016-04-09 03:23:36 +02:00
result, err := hil.Eval(ast, langEvalConfig(nil))
Revert "Revert "core: Add uuid() interpolate function."" This reverts commit 661be01d9b11736ab87d95da1901ca2c8518faac.
2016-03-21 21:14:30 +01:00
if err != nil {
t.Fatalf("err: %s", err)
}
deps: Update call sites of hil.Eval from update hil.Eval() now returns (hil.EvaluationResult, error) instead of (value, type, error). This commit updates the call sites, but retains all previous behaviour. Tests are also updated.
2016-04-09 03:23:36 +02:00
if results[result.Value.(string)] {
t.Fatalf("Got unexpected duplicate uuid: %s", result.Value)
Revert "Revert "core: Add uuid() interpolate function."" This reverts commit 661be01d9b11736ab87d95da1901ca2c8518faac.
2016-03-21 21:14:30 +01:00
}
deps: Update call sites of hil.Eval from update hil.Eval() now returns (hil.EvaluationResult, error) instead of (value, type, error). This commit updates the call sites, but retains all previous behaviour. Tests are also updated.
2016-04-09 03:23:36 +02:00
results[result.Value.(string)] = true
Revert "Revert "core: Add uuid() interpolate function."" This reverts commit 661be01d9b11736ab87d95da1901ca2c8518faac.
2016-03-21 21:14:30 +01:00
}
}
config: add lookup function back
2015-01-13 21:06:04 +01:00
type testFunctionConfig struct {
Cases []testFunctionCase
config: use new API
2015-01-15 07:01:42 +01:00
Vars map[string]ast.Variable
config: add lookup function back
2015-01-13 21:06:04 +01:00
}
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
type testFunctionCase struct {
Input string
Result interface{}
Error bool
}
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
config: add lookup function back
2015-01-13 21:06:04 +01:00
func testFunction(t *testing.T, config testFunctionConfig) {
for i, tc := range config.Cases {
remove config/lang, use hashicorp/hil
2016-01-31 08:38:37 +01:00
ast, err := hil.Parse(tc.Input)
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
if err != nil {
Improve test error messages
2015-05-03 16:53:58 +02:00
t.Fatalf("Case #%d: input: %#v\nerr: %s", i, tc.Input, err)
config: convert fucntions, put functions into Scope
2015-01-13 20:50:44 +01:00
}
deps: Update call sites of hil.Eval from update hil.Eval() now returns (hil.EvaluationResult, error) instead of (value, type, error). This commit updates the call sites, but retains all previous behaviour. Tests are also updated.
2016-04-09 03:23:36 +02:00
result, err := hil.Eval(ast, langEvalConfig(config.Vars))
removed extra parentheses
2015-10-08 14:48:04 +02:00
if err != nil != tc.Error {
Improve test error messages
2015-05-03 16:53:58 +02:00
t.Fatalf("Case #%d:\ninput: %#v\nerr: %s", i, tc.Input, err)
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
}
deps: Update call sites of hil.Eval from update hil.Eval() now returns (hil.EvaluationResult, error) instead of (value, type, error). This commit updates the call sites, but retains all previous behaviour. Tests are also updated.
2016-04-09 03:23:36 +02:00
if !reflect.DeepEqual(result.Value, tc.Result) {
t.Fatalf("%d: bad output for input: %s\n\nOutput: %#v\nExpected: %#v",
i, tc.Input, result.Value, tc.Result)
Added an element interpolation lookup function for accessing a specific index from a list with splat variables
2014-11-07 19:23:02 +01:00
}
}
}