example/centos: tar for x86, aarch64, s390x, and ppc64le

[supakeen]

Tar pipelines for all architectures, based on #209.

[achilleas-k]

So this is where things get interesting. Let's not prematurely optimise or get bogged down on this particular detail, but these two build pipelines present a great opportunity to think about how we might deduplicate these smaller differences.

Here we're looking at two build pipelines, one with and one without forced labels. It's not a huge pipeline so it's fine to have them both, but I can imagine for a lot of things, it'll be really useful to define these outside the include and then have the included fragment/pipeline resolve the variables. What would that look like?

otk.define:
  selinux_build_labels:
    /usr/bin/cp: system_u:object_r:install_exec_t:s0
    /usr/bin/tar: system_u:object_r:install_exec_t:s0

name: build
stages:
  ...
  - type: org.osbuild.selinux
    options:
      labels:
        ${selinux_build_labels}

Would that work?

[achilleas-k]

Interesting issue here:
/usr/bin/cp is an invalid variable name, which makes sense. But it means we can't have dictionaries under otk.define with keys that include those characters. It also means we can't have dictionaries with keys that start with numbers, right?

This might become a problem with content hashes used as object keys in defines, which we might need to use at some point.

[achilleas-k]

Key naming issues aside, the example I posted works, so that's nice.

[supakeen]

We can/could widen our allowed names to allow for subscript, e.g: ${selinux_build_labels[/usr/bin/cp]}.

[achilleas-k]

The problem comes up immediately in the parsing of defines, though. The failure doesn't show up when resolving the key in the object, it's a problem of creating the object to begin with. So we would first have to relax the valid var names (VALID_VAR_NAME_RE).
I think after that, ${selinux_build_labels./usr/bin/cp} isn't an issue.

[achilleas-k]

This works, for example:

diff --git a/src/otk/constant.py b/src/otk/constant.py
index 48d5018..7bd7e0f 100644
--- a/src/otk/constant.py
+++ b/src/otk/constant.py
@@ -11,4 +11,4 @@ PREFIX_EXTERNAL = f"{PREFIX}external."
 NAME_VERSION = f"{PREFIX}version"
 
 # only allow "simple" variable names to avoid confusion
-VALID_VAR_NAME_RE = r"[a-zA-Z][a-zA-Z0-9_]*"
+VALID_VAR_NAME_RE = r".*"
diff --git a/test/data/base/10-subdefines.json b/test/data/base/10-subdefines.json
index c8d7e8d..ee85037 100644
--- a/test/data/base/10-subdefines.json
+++ b/test/data/base/10-subdefines.json
@@ -4,11 +4,13 @@
     {
       "a": 2,
       "outer": 1,
-      "inner": 2
+      "inner": 2,
+      "/path/to/something": "attribute"
     },
     2,
     1,
-    2
+    2,
+    "attribute"
   ],
   "version": "2"
 }
diff --git a/test/data/base/10-subdefines.yaml b/test/data/base/10-subdefines.yaml
index 8134f68..aaea2fa 100644
--- a/test/data/base/10-subdefines.yaml
+++ b/test/data/base/10-subdefines.yaml
@@ -6,6 +6,7 @@ otk.define:
     a: 2  # b.a
     outer: "${a}"  # 1
     inner: "${b.a}"  # 2
+    /path/to/something: "attribute"
 
 
 otk.target.osbuild:
@@ -15,3 +16,4 @@ otk.target.osbuild:
     - "${b.a}"
     - "${b.outer}"
     - "${b.inner}"
+    - "${b./path/to/something}"

though obviously the refs validator shouldn't be so wide open.

[mvo5]

Fwiw, before we do this I would really like us to take a step back and consider this, something like "${b./path/to/something}" looks just strange to my eyes, let's not do this lightly (i.e. let's not do it because we can and it solves the short term issue as we will have to live with the consequences for a long time).

[supakeen]

PR has been rebased and commits have been split out into two logical units.