[cip-dev] isar-cip-core testing

[cip-dev] isar-cip-core testing

[Gylstorff Quirin]

Hi,

I started to implement testing of isar-cip-core with linux-cip-ci.
You can find the prototype at [0].
Currently I can submit test to the my local LAVA Lab and the first
boot test has run successfully (iwg20m).


[0] 
https://gitlab.com/Quirin.Gy/linux-cip-ci/tree/feature/add-isar-cip-testing

Kind regards
Quirin

[cip-dev] isar-cip-core testing

[Chris Paterson]

Hello Quirin,

> From: Gylstorff Quirin <quirin.gylstorff@siemens.com>
> Sent: 10 January 2020 17:10
> 
> Hi,
> 
> I started to implement testing of isar-cip-core with linux-cip-ci.
> You can find the prototype at [0].

Thank you for sharing this.

Once you're happy with it, please sent a merge request to linux-cip-ci and I'll help review it in detail.
I've added you as a developer to the project, so you can add a branch directly to linux-cip-ci, which means the CI will be able to run.

> Currently I can submit test to the my local LAVA Lab and the first
> boot test has run successfully (iwg20m).

Huzzah!

Kind regards, Chris

> 
> 
> [0]
> https://gitlab.com/Quirin.Gy/linux-cip-ci/tree/feature/add-isar-cip-testing
> 
> Kind regards
> Quirin

[cip-dev] gitlab Test artifacts

[Gylstorff Quirin]

Hi Chris,

Is there a reason to upload the artifacts from gitlab to aws. Currently 
the artifacts in gitlab do not expire and are public accessible.

For example 
https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/270427371

If only aws should be used as longt erm storage then maybe we should add 
an expire date or use caches instead of artifacts for the gitlab ci builds.

Kind regards,
Quirin

[cip-dev] gitlab Test artifacts

[Chris Paterson]

Hello Quirin,

> From: Gylstorff Quirin <quirin.gylstorff@siemens.com>
> Sent: 23 January 2020 09:32
> 
> Hi Chris,
> 
> Is there a reason to upload the artifacts from gitlab to aws. Currently
> the artifacts in gitlab do not expire and are public accessible.

Currently the artifacts (Kernel image/DTBs) from a 'build' job are stored as artifacts in GitLab so that they are easily available for 'test' jobs to use.
These test jobs then upload the artifacts to AWS where they can be accessed by the LAVA labs.

Why don't the LAVA labs just fetch the binaries from GitLab? Good question.
Partly because CIP was already using AWS and partly because I never got around to trying.

> 
> For example
> https://gitlab.com/cip-project/cip-kernel/linux-cip/-/jobs/270427371
> 
> If only aws should be used as longt erm storage then maybe we should add
> an expire date or use caches instead of artifacts for the gitlab ci builds.

The benefit of using artifacts over caches in GitLab is that objects stored as artifacts can be easily accessed by users through the GitLab website or API.
Perhaps useful if someone wants to run some tests locally, and easier to do then finding the appropriate files in AWS.

Yes, there should probably be an expiry on these artifacts (artifacts:expire_in), but as the storage is all controlled/payed for by GitLab it's not a direct issue for CIP.
I'll add a 1 month limit for now.

One thing I haven't tried yet is playing around with using a cache for build objects to speed up build times, perhaps useful to store the SSTATE CACHE from OE builds.

Kind regards, Chris

> 
> Kind regards,
> Quirin