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

156 lines
6.0 KiB
Go
Raw Normal View History

lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
package lang
import (
"fmt"
lang: yamldecode and yamlencode functions These follow the same principle as jsondecode and jsonencode, but use YAML instead of JSON. YAML has a much more complex information model than JSON, so we can only support a subset of it during decoding, but hopefully the subset supported here is a useful one. Because there are many different ways to _generate_ YAML, the yamlencode function is forced to make some decisions, and those decisions are likely to affect compatibility with other real-world YAML parsers. Although the format here is intended to be generic and compatible, we may find that there are problems with it that'll we'll want to adjust for in a future release, so yamlencode is therefore marked as experimental for now until the underlying library is ready to commit to ongoing byte-for-byte compatibility in serialization. The main use-case here is met by yamldecode, which will allow reading in files written in YAML format by humans for use in Terraform modules, in situations where a higher-level input format than direct Terraform language declarations is helpful.
2019-05-26 19:25:18 +02:00
ctyyaml "github.com/zclconf/go-cty-yaml"
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
"github.com/zclconf/go-cty/cty"
"github.com/zclconf/go-cty/cty/function"
"github.com/zclconf/go-cty/cty/function/stdlib"
lang/funcs: port some of Terraform's built-in functions These implementations are adaptations of the existing implementations in config/interpolate_funcs.go, updated to work with the cty API. The set of functions chosen here was motivated mainly by what Terraform's existing context tests depend on, so we can get the contexts tests back into good shape before fleshing out the rest of these functions.
2018-05-22 02:39:26 +02:00
"github.com/hashicorp/terraform/lang/funcs"
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
)
var impureFunctions = []string{
cleanup comments for nicer godocs
2018-05-23 18:38:12 +02:00
"bcrypt",
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
"timestamp",
"uuid",
}
// Functions returns the set of functions that should be used to when evaluating
// expressions in the receiving scope.
func (s *Scope) Functions() map[string]function.Function {
s.funcsLock.Lock()
if s.funcs == nil {
lang/funcs: port some of Terraform's built-in functions These implementations are adaptations of the existing implementations in config/interpolate_funcs.go, updated to work with the cty API. The set of functions chosen here was motivated mainly by what Terraform's existing context tests depend on, so we can get the contexts tests back into good shape before fleshing out the rest of these functions.
2018-05-22 02:39:26 +02:00
// Some of our functions are just directly the cty stdlib functions.
// Others are implemented in the subdirectory "funcs" here in this
// repository. New functions should generally start out their lives
// in the "funcs" directory and potentially graduate to cty stdlib
// later if the functionality seems to be something domain-agnostic
// that would be useful to all applications using cty functions.
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
s.funcs = map[string]function.Function{
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"abs": stdlib.AbsoluteFunc,
lang/funcs: add "abspath" function (#21409)
2019-07-02 14:30:30 +02:00
"abspath": funcs.AbsPathFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"basename": funcs.BasenameFunc,
"base64decode": funcs.Base64DecodeFunc,
"base64encode": funcs.Base64EncodeFunc,
"base64gzip": funcs.Base64GzipFunc,
"base64sha256": funcs.Base64Sha256Func,
"base64sha512": funcs.Base64Sha512Func,
"bcrypt": funcs.BcryptFunc,
"ceil": funcs.CeilFunc,
"chomp": funcs.ChompFunc,
"cidrhost": funcs.CidrHostFunc,
"cidrnetmask": funcs.CidrNetmaskFunc,
"cidrsubnet": funcs.CidrSubnetFunc,
funcs/coalesce: return the first non-null, non-empty-string element from a sequence (#21002) * funcs/coalesce: return the first non-null, non-empty element from a sequence. The go-cty coalesce function, which was originally used here, returns the first non-null element from a sequence. Terraform 0.11's coalesce, however, returns the first non-empty string from a list of strings. This new coalesce function aims to preserve terraform's documented functionality while adding support for additional argument types. The tests include those in go-cty and adapted tests from the 0.11 version of coalesce. * website/docs: update coalesce function document
2019-04-12 19:57:52 +02:00
"coalesce": funcs.CoalesceFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"coalescelist": funcs.CoalesceListFunc,
"compact": funcs.CompactFunc,
"concat": stdlib.ConcatFunc,
"contains": funcs.ContainsFunc,
"csvdecode": stdlib.CSVDecodeFunc,
"dirname": funcs.DirnameFunc,
"distinct": funcs.DistinctFunc,
"element": funcs.ElementFunc,
"chunklist": funcs.ChunklistFunc,
"file": funcs.MakeFileFunc(s.BaseDir, false),
"fileexists": funcs.MakeFileExistsFunc(s.BaseDir),
"filebase64": funcs.MakeFileFunc(s.BaseDir, true),
"filebase64sha256": funcs.MakeFileBase64Sha256Func(s.BaseDir),
"filebase64sha512": funcs.MakeFileBase64Sha512Func(s.BaseDir),
"filemd5": funcs.MakeFileMd5Func(s.BaseDir),
"filesha1": funcs.MakeFileSha1Func(s.BaseDir),
"filesha256": funcs.MakeFileSha256Func(s.BaseDir),
"filesha512": funcs.MakeFileSha512Func(s.BaseDir),
"flatten": funcs.FlattenFunc,
"floor": funcs.FloorFunc,
"format": stdlib.FormatFunc,
"formatdate": stdlib.FormatDateFunc,
"formatlist": stdlib.FormatListFunc,
"indent": funcs.IndentFunc,
"index": funcs.IndexFunc,
"join": funcs.JoinFunc,
"jsondecode": stdlib.JSONDecodeFunc,
"jsonencode": stdlib.JSONEncodeFunc,
"keys": funcs.KeysFunc,
"length": funcs.LengthFunc,
"list": funcs.ListFunc,
"log": funcs.LogFunc,
"lookup": funcs.LookupFunc,
"lower": stdlib.LowerFunc,
"map": funcs.MapFunc,
"matchkeys": funcs.MatchkeysFunc,
"max": stdlib.MaxFunc,
"md5": funcs.Md5Func,
"merge": funcs.MergeFunc,
"min": stdlib.MinFunc,
"pathexpand": funcs.PathExpandFunc,
"pow": funcs.PowFunc,
lang: "range" function This is similar to the function of the same name in Python, generating a sequence of numbers as a list that can then be used in other sequence-oriented operations. The primary use-case for it is to turn a count expressed as a number into a list of that length, which can then be iterated over or passed to a collection function to produce that number of something else, as shown in the example at the end of its documentation page.
2019-05-26 22:09:44 +02:00
"range": stdlib.RangeFunc,
lang: "regex" and "regexall" functions These existing upstream cty functions allow matching strings against regular expression patterns, which can be useful if you need to consume a non-standard string format that Terraform doesn't (and can't) have a built-in function for.
2019-08-06 17:21:22 +02:00
"regex": stdlib.RegexFunc,
"regexall": stdlib.RegexAllFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"replace": funcs.ReplaceFunc,
lang/funcs: Port the "reverse" function from the old functions set This has the same functionality as the "reverse" function that was implemented in the "config" package, but adapted to the new language type system.
2019-03-20 01:09:01 +01:00
"reverse": funcs.ReverseFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"rsadecrypt": funcs.RsaDecryptFunc,
"setintersection": stdlib.SetIntersectionFunc,
"setproduct": funcs.SetProductFunc,
"setunion": stdlib.SetUnionFunc,
"sha1": funcs.Sha1Func,
"sha256": funcs.Sha256Func,
"sha512": funcs.Sha512Func,
"signum": funcs.SignumFunc,
"slice": funcs.SliceFunc,
"sort": funcs.SortFunc,
"split": funcs.SplitFunc,
lang/funcs: add 'strrev' interpolation function. (#21091)
2019-04-24 20:52:39 +02:00
"strrev": stdlib.ReverseFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"substr": stdlib.SubstrFunc,
"timestamp": funcs.TimestampFunc,
"timeadd": funcs.TimeAddFunc,
"title": funcs.TitleFunc,
"tostring": funcs.MakeToFunc(cty.String),
"tonumber": funcs.MakeToFunc(cty.Number),
"tobool": funcs.MakeToFunc(cty.Bool),
"toset": funcs.MakeToFunc(cty.Set(cty.DynamicPseudoType)),
"tolist": funcs.MakeToFunc(cty.List(cty.DynamicPseudoType)),
"tomap": funcs.MakeToFunc(cty.Map(cty.DynamicPseudoType)),
"transpose": funcs.TransposeFunc,
"trimspace": funcs.TrimSpaceFunc,
"upper": stdlib.UpperFunc,
"urlencode": funcs.URLEncodeFunc,
"uuid": funcs.UUIDFunc,
lang/funcs: New "uuidv5" function This generates name-based uuids, rather than pseudorandom uuids as with the "uuid" function.
2019-05-08 11:13:30 +02:00
"uuidv5": funcs.UUIDV5Func,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"values": funcs.ValuesFunc,
lang: yamldecode and yamlencode functions These follow the same principle as jsondecode and jsonencode, but use YAML instead of JSON. YAML has a much more complex information model than JSON, so we can only support a subset of it during decoding, but hopefully the subset supported here is a useful one. Because there are many different ways to _generate_ YAML, the yamlencode function is forced to make some decisions, and those decisions are likely to affect compatibility with other real-world YAML parsers. Although the format here is intended to be generic and compatible, we may find that there are problems with it that'll we'll want to adjust for in a future release, so yamlencode is therefore marked as experimental for now until the underlying library is ready to commit to ongoing byte-for-byte compatibility in serialization. The main use-case here is met by yamldecode, which will allow reading in files written in YAML format by humans for use in Terraform modules, in situations where a higher-level input format than direct Terraform language declarations is helpful.
2019-05-26 19:25:18 +02:00
"yamldecode": ctyyaml.YAMLDecodeFunc,
"yamlencode": ctyyaml.YAMLEncodeFunc,
lang: New file-hashing functions In prior versions, we recommended using hash functions in conjunction with the file function as an idiom for detecting changes to upstream blobs without fetching and comparing the whole blob. That approach relied on us being able to return raw binary data from file(...). Since Terraform strings pass through intermediate representations that are not binary-safe (e.g. the JSON state), there was a risk of string corruption in prior versions which we have avoided for 0.12 by requiring that file(...) be used only with UTF-8 text files. The specific case of returning a string and immediately passing it into another function was not actually subject to that corruption risk, since the HIL interpreter would just pass the string through verbatim, but this is still now forbidden as a result of the stricter handling of file(...). To avoid breaking these use-cases, here we introduce variants of the hash functions a with "file" prefix that take a filename for a disk file to hash rather than hashing the given string directly. The configuration upgrade tool also now includes a rule to detect the documented idiom and rewrite it into a single function call for one of these new functions. This does cause a bit of function sprawl, but that seems preferable to introducing more complex rules for when file(...) can and cannot read binary files, making the behavior of these various functions easier to understand in isolation.
2019-01-25 18:16:43 +01:00
"zipmap": funcs.ZipmapFunc,
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
}
lang/funcs: templatefile function This function is similar to the template_file data source offered by the template provider, but having it built in to the language makes it more convenient to use, allowing templates to be rendered from files anywhere an inline template would normally be allowed: user_data = templatefile("${path.module}/userdata.tmpl", { hostname = format("petserver%02d", count.index) }) Unlike the template_file data source, this function allows values of any type in its variables map, passing them through verbatim to the template. Its tighter integration with Terraform also allows it to return better error messages with source location information from the template itself. The template_file data source was originally created to work around the fact that HIL didn't have any support for map values at the time, and even once map support was added it wasn't very usable. With HCL2 expressions, there's little reason left to use a data source to render a template; the only remaining reason left to use template_file is to render a template that is constructed dynamically during the Terraform run, which is a very rare need.
2018-12-21 02:42:42 +01:00
s.funcs["templatefile"] = funcs.MakeTemplateFileFunc(s.BaseDir, func() map[string]function.Function {
// The templatefile function prevents recursive calls to itself
// by copying this map and overwriting the "templatefile" entry.
return s.funcs
})
lang: new package for the runtime parts of the config language Whereas package "configs" deals with the static structure of the configuration language, this new package "lang" deals with the dynamic aspects such as expression evaluation. So far this mainly consists of populating a hcl.EvalContext that contains the values necessary to evaluate a block or an expression. There is also special handling here for dynamic block generation using the HCL "dynblock" extension, which is exposed in the public interface (rather than hiding it as an implementation detail of EvalBlock) so that the caller can then extract proper source locations for any result values using the expanded body. This also includes the beginnings of a replacement for the function table handling that currently lives in the old "config" package, but most of the functions are not yet ported and so this will expand in subsequent commits.
2018-04-04 03:11:28 +02:00
if s.PureOnly {
// Force our few impure functions to return unknown so that we
// can defer evaluating them until a later pass.
for _, name := range impureFunctions {
s.funcs[name] = function.Unpredictable(s.funcs[name])
}
}
}
s.funcsLock.Unlock()
return s.funcs
}
var unimplFunc = function.New(&function.Spec{
Type: func([]cty.Value) (cty.Type, error) {
return cty.DynamicPseudoType, fmt.Errorf("function not yet implemented")
},
Impl: func([]cty.Value, cty.Type) (cty.Value, error) {
return cty.DynamicVal, fmt.Errorf("function not yet implemented")
},
})