All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris.Paterson2@renesas.com (Chris Paterson)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] gitlab Test artifacts
Date: Thu, 23 Jan 2020 11:43:31 +0000	[thread overview]
Message-ID: <OSBPR01MB228045EBD443807F92D64CA0B70F0@OSBPR01MB2280.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <a2d7cda0-1858-fa1c-add2-70916e4df493@siemens.com>

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

      reply	other threads:[~2020-01-23 11:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 17:09 [cip-dev] isar-cip-core testing Gylstorff Quirin
2020-01-13 12:10 ` Chris Paterson
2020-01-23  9:32   ` [cip-dev] gitlab Test artifacts Gylstorff Quirin
2020-01-23 11:43     ` Chris Paterson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OSBPR01MB228045EBD443807F92D64CA0B70F0@OSBPR01MB2280.jpnprd01.prod.outlook.com \
    --to=chris.paterson2@renesas.com \
    --cc=cip-dev@lists.cip-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.