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 <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.
>
Ok, then I will drop TARGET_EXTENSION. Also JOB_TEMPLATE_PATH seems
unneeded without a practical case.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
