Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
On 07.01.22 15:40, Gylstorff Quirin wrote:
>
>
> 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
>>
>> This makes the inclusion structure more regular and reduces
>> duplications
>> by re-using the kernel_.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_.yml and
>> kernel-
>> specific job level, respectively.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> 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.
>
Ok, then I will drop TARGET_EXTENSION. Also JOB_TEMPLATE_PATH seems
unneeded without a practical case.
Jan
--
Siemens AG, Technology
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
This makes the inclusion structure more regular and reduces
duplications
by re-using the kernel_.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_.yml and
kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka
---
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
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
This makes the inclusion structure more regular and reduces
duplications
by re-using the kernel_.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_.yml and
kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka
---
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
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
This makes the inclusion structure more regular and reduces
duplications
by re-using the kernel_.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_.yml and kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka
---
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
- ISAR_IMAGE
This is mentioned in section `LAVA Template variable`
- ISAR_DISTRIBUTION
This is mentioned in section `LAVA Template variable`
- S3_BUCKET_URL > - AWS_*
These are missing
Why is JOB_TEMPLATE_PATH configurable (use case)?
The intention was to allow URLs to test new Templates.
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.
Jan
Quirin
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
On 07.01.22 15:09, Jan Kiszka via Xenomai 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
>>>
>>> This makes the inclusion structure more regular and reduces
>>> duplications
>>> by re-using the kernel_.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_.yml and kernel-
>>> specific job level, respectively.
>>>
>>> Signed-off-by: Jan Kiszka
>>> ---
>>> 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)
> - ISAR_IMAGE
> - ISAR_DISTRIBUTION
> - S3_BUCKET_URL
> - AWS_*
- USE_S3_BUCKET
>
> Why is JOB_TEMPLATE_PATH configurable (use case)?
> What is the use case for TARGET_EXTENSION?
>
> Jan
>
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
>>
>> This makes the inclusion structure more regular and reduces
>> duplications
>> by re-using the kernel_.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_.yml and kernel-
>> specific job level, respectively.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> 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)
- ISAR_IMAGE
- ISAR_DISTRIBUTION
- S3_BUCKET_URL
- AWS_*
Why is JOB_TEMPLATE_PATH configurable (use case)?
What is the use case for TARGET_EXTENSION?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
>
> This makes the inclusion structure more regular and reduces
> duplications
> by re-using the kernel_.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_.yml and kernel-
> specific job level, respectively.
>
> Signed-off-by: Jan Kiszka
> ---
> 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.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
This makes the inclusion structure more regular and reduces
duplications
by re-using the kernel_.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_.yml and kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka
---
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.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
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
This makes the inclusion structure more regular and reduces duplications
by re-using the kernel_.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_.yml and kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka
---
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.
Jan
Quirin
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
On 07.01.22 14:36, Gylstorff Quirin wrote:
>
>
> On 1/7/22 13:00, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> This makes the inclusion structure more regular and reduces duplications
>> by re-using the kernel_.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_.yml and kernel-
>> specific job level, respectively.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> 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?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [xenomai-images][PATCH v3 2/5] ci: Refactor inclusions
On 1/7/22 13:00, Jan Kiszka wrote:
From: Jan Kiszka
This makes the inclusion structure more regular and reduces duplications
by re-using the kernel_.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_.yml and kernel-
specific job level, respectively.
Signed-off-by: Jan Kiszka
---
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.
Quirin
default:
image: ghcr.io/siemens/kas/kas-isar:2.6.3
diff --git a/ci/kernel_4_19_xenomai_next.yml b/ci/kernel_4_19.yml
similarity index 71%
rename from ci/kernel_4_19_xenomai_next.yml
rename to ci/kernel_4_19.yml
index 6ae2c35..c55b26a 100644
--- a/ci/kernel_4_19_xenomai_next.yml
+++ b/ci/kernel_4_19.yml
@@ -1,7 +1,7 @@
#
# Xenomai Real-Time System
#
-# Copyright (c) Siemens AG, 2019 - 2020
+# Copyright (c) Siemens AG, 2019 - 2022
#
# Authors:
# Quirin Gylstorff
@@ -13,76 +13,70 @@ build-4.19:qemu-amd64:
extends: .build:qemu-amd64
variables:
LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
-DEPLOY_DIR_EXTENSION: "4.19"
+KERNEL_VERSION: "4.19"
lava-test-4.19:qemu-amd64:
needs: [ "build-4.19:qemu-amd64" ]
extends: .lava-test:qemu-amd64
variables:
-DEPLOY_DIR_EXTENSION: "4.19"
-BUILD_IDENTIFIER: "4.19"
+KERNEL_VERSION: "4.19"
build-4.19:qemu-armhf:
extends: .build:qemu-armhf
variables:
LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
-DEPLOY_DIR_EXTENSION: "4.19"
+KERNEL_VERSION: "4.19"
lava-test-4.19:qemu-armhf:
needs: [ "build-4.19:qemu-armhf" ]
extends: .lava-test:qemu-armhf
variables:
-DEPLOY_DIR_EXTENSION: "4.19"
-BUILD_IDENTIFIER: "4.19"
+KERNEL_VERSION: "4.19"
build-4.19:qemu-arm64:
extends: .build:qemu-arm64
variables:
LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
-DEPLOY_DIR_EXTENSION: "4.19"
+KERNEL_VERSION: "4.19"
lava-test-4.19:qemu-arm64:
needs: [ "build-4.19:qemu-arm64" ]
extends: .lava-test:qemu-arm64
variables:
-DEPLOY_DIR_EXTENSION: "4.19"
-BUILD_IDENTIFIER: "4.19"
+KERNEL_VERSION: "4.19"
build-4.19:hikey:
extends: .build:hikey
variables:
LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
-DEPLOY_DIR_EXTENSION: "4.19"
+KERNEL_VERSION: "4.19"
lava-test-4.19:hikey:
needs: [ "build-4.19:hikey" ]
extends: .lava-test:hikey
variables:
-DEPLOY_DIR_EXTENSION: "4.19"
-BUILD_IDENTIFIER: "4.19"
+KERNEL_VERSION: "4.19"
build-4.19:beagle-bone-black:
extends: .build:beagle-bone-black
variables:
LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
-DEPLOY_DIR_EXTENSION: "4.19"
+KERNEL_VERSION: "4.19"
lava-test-4.19:beagle-bone-black:
needs: [ "build-4.19:beagle-bone-black" ]
extends: .lava-test:beagle-bone-black
variables:
-DEPLOY_DIR_EXTENSION: "4.19"
-BUILD_IDENTIFIER: "4.19"
+KERNEL_VERSION: "4.19"
build-4.19:x86-64-efi:
extends: .build:x86-64-efi
variables:
LINUX_BUILD_OPTION: ":opt-linux-latest-4.19.yml"
-DEPLOY_DIR_EXTENSION: "4.19"
+KERNEL_VERSION: "4.19"
lava-test-4.19:x86-64-efi:
needs: [ "build-4.19:x86-64-efi" ]
extends: .lava-test:x86-64-efi
variables:
-DEPLOY_DIR_EXTENSION: "4.19"
-BUILD_IDENTIFIER: "4.19"
+KERNEL_VERSION: "4.19"
diff --git a/ci/kernel_5_10_xenomai_next.yml b/ci/kernel_5_10.yml
