Values
The types of values you can provide for configuring Flinkwerk.
Name
The Flinkwerk Config file allows you to define various names, e.g. of the project owner, the project name, an application name, cluster name, environment name, registry name, etc. For example:
owner: my-org
name: my-project
Such names (my-org,my-project) are required to be an alphanumeric string. They must all be lowercase, maximum 64 characters, a text with everything except 0-9 and a-z replaced with -. No leading / trailing -, in Regex terms: [a-z0-9](([_.]?|-{0,2})[a-z0-9]+.
Project scope
Names of dependencies or environments must be unique within a dependencies definition and isolated from that within an environments configuration per Flinkwerk project. The same names can be used in other projects, because the respective configurations apply only to the project which contains them. This means that application and environment definitions in one project cannot be reused in another project.
Account scope
Contrary to the previous paragraph, names of global resources such as clusters or registries must be unique across all your projects. This means that you can define a resource name only once per Flinkwerk account. This constraint ensures that you can reuse resources in all projects owned by your Flinkwerk account without conflicts arising due to duplicate resource definitions.
Names which have already been used in dependencies or environments definitions in the same project where you defined global resources, can also be used in global resources definitions without a conflict.
SKU
The sku field is used throughout your Flinkwerk Config file to uniquely identify products in Flinkwerk Marketplace which you want to include in your project.
The SKU includes the username of a project owner, who is identical with the product vendor, as well as a project name - both separated by a forward slash.
For example:
sku: my-org/my-project
An SKU must be all lowercase and consist of words separated by - or _. The complete name must match this regular expression: ^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]?|-{0,2})[a-z0-9]+)*$.
Version
You can apply version control mechanisms for applications used in your project. This applies to applications inside as well as outside of Flinkwerk Marketplace.
For example, if you wanted to use an application from Flinkwerk Marketplace, you could define the following dependency:
dependencies:
my-app-name:
type: app
sku: their-org/their-product
This would always deploy the latest available version of the application.
You could constrain the dependency to a specific version:
dependencies:
my-app-name:
type: app
sku: their-org/their-product:1.0.0
Alternatively, you could define a version in a separate YAML key:
dependencies:
my-app-name:
type: app
sku: their-org/their-product
version: 1.0.0
If you wanted more flexibility and allow deployment of all upcoming minor versions that belong to v1.0.x, you would specify:
dependencies:
my-app-name:
type: app
sku: their-org/their-product:1.0.*
Find below the version patterns you can apply in the Flinkwerk Config file.
note
When referencing Helm charts, the version attribute denotes the chart version, not the application version.
Exact version constraint
You can specify the exact version of an application. This will tell Flinkwerk to install this version and this version only.
Example: 1.0.2
Version range (>, >=, <, <=, !=)
By using comparison operators you can specify ranges of valid versions. Valid operators are >, >=, <, <=, !=.
You can define multiple ranges. Ranges separated by a space ( ) or comma (,) will be treated as a logical AND. A double pipe (||) will be treated as a logical OR. AND has higher precedence than OR.
note
Be careful when using unbounded ranges as you might end up unexpectedly installing versions that break backwards compatibility. Consider using the caret operator instead for safety.
Examples:
>=1.0>=1.0 <2.0>=1.0 <1.1 || >=1.2
Hyphenated version range (-)
Inclusive set of versions. Partial versions on the right include are completed with a wildcard. For example 1.0 - 2.0 is equivalent to >=1.0.0 <2.1 as the 2.0 becomes 2.0.*. On the other hand 1.0.0 - 2.1.0 is equivalent to >=1.0.0 <=2.1.0.
Example: 1.0 - 2.0
Wildcard version range (.*)
You can specify a pattern with a * wildcard. 1.0.* is the equivalent of >=1.0 <1.1.
Example: 1.0.*
Next significant release operators (~, ^)
Tilde Version Range (~)
The ~ operator is best explained by example: ~1.2 is equivalent to >=1.2 <2.0.0, while ~1.2.3 is equivalent to >=1.2.3 <1.3.0. As you can see, it is mostly useful for projects respecting semantic versioning. A common usage would be to mark the minimum minor version you depend on, like ~1.2 (which allows anything up to, but not including, 2.0). Since in theory there should be no backwards compatibility breaks until 2.0, that works well. Another way of looking at it is that using ~ specifies a minimum version, but allows the last digit specified to go up.
Example: ~1.2
note
Although 2.0-beta.1 is strictly before 2.0, a version constraint like ~1.2 would not install it. As said above ~1.2 only means the .2 can change but the 1. part is fixed.
The ~ operator has an exception on its behavior for the major release number. This means for example that ~1 is the same as ~1.0 as it will not allow the major number to increase trying to keep backwards compatibility.
Caret Version Range (^)
The ^ operator behaves very similarly, but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.
Example: ^1.2.3
Variable
Specify parameter values as environment variables to keep your configuration dynamic.