On 1/7/22 15:35, Jan Kiszka wrote:
On 07.01.22 15:27, Gylstorff Quirin wrote:
On 1/7/22 15:09, Jan Kiszka wrote:
On 07.01.22 14:58, Jan Kiszka via Xenomai wrote:
On 07.01.22 14:49, Jan Kiszka via Xenomai wrote:
On 07.01.22 14:41, Gylstorff Quirin wrote:
On 1/7/22 14:40, Jan Kiszka wrote:
On 07.01.22 14:36, Gylstorff Quirin wrote:
On 1/7/22 13:00, Jan Kiszka wrote:
From: Jan Kiszka <jan.kis...@siemens.com>
This makes the inclusion structure more regular and reduces
duplications
by re-using the kernel_<version>.yml files for 3.1 and next. The
trick
is that we pull common variables to additional top-level
'variables:'
blocks and only set what differes in the job-specific 'variables:'.
DEPLOY_DIR_EXTENSION is now identical to BUILD_IDENTIFIER, and the
latter is derived from the XENOMAI_VERSION and KERNEL_VERSION. Only
those version variables are set at xenomai_<version>.yml and
kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
---
ci/gitlab-ci-base.yml | 3 +-
..._4_19_xenomai_next.yml => kernel_4_19.yml} | 32 +++----
..._5_10_xenomai_next.yml => kernel_5_10.yml} | 32 +++----
...el_5_4_xenomai_next.yml => kernel_5_4.yml} | 32 +++----
ci/xenomai_3_0_x.yml | 23 ++---
ci/xenomai_3_1_x.yml | 91
++-----------------
ci/xenomai_next.yml | 13 ++-
7 files changed, 64 insertions(+), 162 deletions(-)
rename ci/{kernel_4_19_xenomai_next.yml => kernel_4_19.yml}
(71%)
rename ci/{kernel_5_10_xenomai_next.yml => kernel_5_10.yml}
(71%)
rename ci/{kernel_5_4_xenomai_next.yml => kernel_5_4.yml} (71%)
diff --git a/ci/gitlab-ci-base.yml b/ci/gitlab-ci-base.yml
index 367085d..27271ce 100644
--- a/ci/gitlab-ci-base.yml
+++ b/ci/gitlab-ci-base.yml
@@ -18,10 +18,11 @@ variables:
https_proxy: "$HTTPS_PROXY"
ftp_proxy: "$FTP_PROXY"
no_proxy: "$NO_PROXY"
- XENOMAI_BUILD_OPTION: ":opt-xenomai-next.yml"
ISAR_IMAGE: demo-image
ISAR_DISTRIBUTION: xenomai-demo
LAVA_TESTS_ENABLED: "true"
+ DEPLOY_DIR_EXTENSION: "${BUILD_IDENTIFIER}"
+ BUILD_IDENTIFIER:
"xenomai-${XENOMAI_VERSION}_kernel-${KERNEL_VERSION}"
The variable DEPLOY_DIR_EXTENSIONS is no longer necessary. We could
replace it in the scripts `deploy_to_aws.sh` and `run-lava-tests.sh`
with BUILD_IDENTIFIER.
DEPLOY_DIR_EXTENSION was mentioned somewhere in the README, so I
didn't
dare to touch it. How should tests/README.md adjusted best then?
It can be removed.
Why? It's like to leave that note in the commit log.
Looking at tests/README.md, the list of variables that test side
consumes from the CI side seems a bit incomplete. I rather feel like we
should then add BUILD_IDENTIFIER, and bunch of others more.
Missing:
- CI_PIPELINE_ID (probably auto-set by gitlab)
Yeah this is a gitlab variable
Internal interface, not to be set via CI variable. And that is the
reason to drop DEPLOY_DIR_EXTENSION as well - understood now.
- ISAR_IMAGE
This is mentioned in section `LAVA Template variable`
- ISAR_DISTRIBUTION
This is mentioned in section `LAVA Template variable`
Right.
- S3_BUCKET_URL > - AWS_*
These are missing
I'm writing a patch.
Why is JOB_TEMPLATE_PATH configurable (use case)?
The intention was to allow URLs to test new Templates.
Wouldn't you fork and patch the existing ones for that?
What is the use case for TARGET_EXTENSION?
The original use case was to to add additional kas options over the run
pipeline button, e.g. DEBUG build.
I thought that's what BUILD_OPTIONS is for. TARGET_EXTENSION only seems
to adjust the job name and has otherwise not functional effect.
Jan
A sorry - It was introduced as we extracted the artifacts from gitlab
artifact store and was used to differentiate between different builds.
Quirin
