Re: [Xen-devel] [PATCH v2 0/8] Using GitLab CI for build testing

[Doug Goldstein]

On 3/15/18 8:55 PM, John Thomson wrote:
> Hi,
> 
> I have some suggestions / queries.
> I package Xen using GitLab CI for my use: 
> https://gitlab.com/archlinux-packages-johnth/xen/pipelines
> My examples here are just mock-ups and not tested.
> 
> On Fri, 16 Mar 2018, at 04:21, Doug Goldstein wrote:
>> Example run: https://gitlab.com/cardoe/xen/pipelines/18968075
> 
> - You probably want to set "XEN_TARGET_ARCH". The example build misses tools.
> job:
>   variables:
> ...
> XEN_TARGET_ARCH: x86_64

Agreed. I've added for a v3.

> 
> 
> - Is it worth storing the resultant built files as artifacts?
>   This way they can be downloaded or tested later.
> 
> artifacts:
>   paths:
> - 'dist'

I agree as well. I was likely going to keep them for a week only to
start with. Internally I use the artifacts to do some basic boot tests
with Xen.

> 
>> Currently the example uses one stage called build and all the different 
>> distros are different jobs.  
> 
> - Is is worth caching and artifacting the build (tools) dependencies as a job,
>   so that each CI job does not hit the dependency Xen repos and websites for 
> the same data,
>   and you have an easily accessible pre-build state?
>   This may need an empty job for collect stage where not wanted? I am unsure 
> if you can skip a first stage.
> 
> stages:
>   - collect
>   - build
> 
> collect:tools:
>   stage: collect
>   script:
> - Clone all tools dependency repos & downloads
> - Move files into place, and set repo URLs (example; QEMU_UPSTREAM_URL) 
> to the local copies.
>   artifacts:
> untracked: true
>   cache:
> untracked: true
> 
> build-job-example:
>   ...
>   dependencies:
> - collect:tools

Good suggestion. We'll also be able to ensure all the builds used the
same revs in case they start at different times.


> 
> - My build log exceeds the GitLab CI Job limit. You may not hit this limit, 
> then you can ignore this.
>   It looks like this, at the end of the GitLab CI log, but mid-way through 
> the job log:
>   ...
>   "Job's log exceeded limit of 4194304 bytes."
>   To work around this, I log to a file, then store this file as an artifact.
>   These can then be downloaded later.
>   This could be something like:
> 
> artifacts:
>   paths:
> - '*.log'
>   when: always
> 
> job:
>   ...
>   script:
> - ./scripts/travis-build 2>&1 | tee build.log
> 
> 
> Cheers,
> 

Good to know. Thanks!

I appreciate the feedback and I'll incorporate your suggestions.
-- 
Doug Goldstein

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 0/8] Using GitLab CI for build testing

[John Thomson]

Hi,

I have some suggestions / queries.
I package Xen using GitLab CI for my use: 
https://gitlab.com/archlinux-packages-johnth/xen/pipelines
My examples here are just mock-ups and not tested.

On Fri, 16 Mar 2018, at 04:21, Doug Goldstein wrote:
> Example run: https://gitlab.com/cardoe/xen/pipelines/18968075

- You probably want to set "XEN_TARGET_ARCH". The example build misses tools.
job:
  variables:
...
XEN_TARGET_ARCH: x86_64


- Is it worth storing the resultant built files as artifacts?
  This way they can be downloaded or tested later.

artifacts:
  paths:
- 'dist'

> Currently the example uses one stage called build and all the different 
> distros are different jobs.  

- Is is worth caching and artifacting the build (tools) dependencies as a job,
  so that each CI job does not hit the dependency Xen repos and websites for 
the same data,
  and you have an easily accessible pre-build state?
  This may need an empty job for collect stage where not wanted? I am unsure if 
you can skip a first stage.

stages:
  - collect
  - build

collect:tools:
  stage: collect
  script:
- Clone all tools dependency repos & downloads
- Move files into place, and set repo URLs (example; QEMU_UPSTREAM_URL) to 
the local copies.
  artifacts:
untracked: true
  cache:
untracked: true

build-job-example:
  ...
  dependencies:
- collect:tools

- My build log exceeds the GitLab CI Job limit. You may not hit this limit, 
then you can ignore this.
  It looks like this, at the end of the GitLab CI log, but mid-way through the 
job log:
  ...
  "Job's log exceeded limit of 4194304 bytes."
  To work around this, I log to a file, then store this file as an artifact.
  These can then be downloaded later.
  This could be something like:

artifacts:
  paths:
- '*.log'
  when: always

job:
  ...
  script:
- ./scripts/travis-build 2>&1 | tee build.log


Cheers,
-- 
  John Thomson

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 0/8] Using GitLab CI for build testing

[Konrad Rzeszutek Wilk]

On Thu, Mar 15, 2018 at 01:21:08PM -0500, Doug Goldstein wrote:
> Really early work on switching over to using GitLab CI over
> Travis CI. GitLab is a competitor to GitHub with some advantages
> such as an integrated CI system with a lot more flexibility
> and control. It additionally is fully open sourced unlike GitHub
> and Travis CI. We can even run an instance if that is preferred
> over using the hosted instance.
> 
> This change uses GitLab CI's ability to use Docker based runners
> for running tests. With GitHub we also use a Docker based runner
> but we are limited to one Docker container that is then morphed
> a number of different ways. With this approach we can specify
> different Docker containers for every run (or use the same). By
> using different Docker containers we can build environments that
> match systems where Xen can and should build. Using this
> approach we should be able to cutdown on the number of surpise
> build failures encountered by users.
> 
> Worth noting another advantage is that builders can be VMs or even
> physical hosts as well. So we can have a FreeBSD VM that can be a
> build environment.
> 
> Further more the above link is to a GitLab pipeline, pipelines are
> made of stages which are further composed of jobs. Currently the
> example uses one stage called build and all the different distros
> are different jobs.  But there's a lot of flexibility as to what
> can be done here. There can be stages that check code style or other
> pre-flight checks that people may be interested. There can be stages
> that happen after the build stage as well such as some simple tests
> (e.g. I use it to run the just built xen.gz with an initramfs only
> dom0 that contains a small Alpine Linux VM that spits out a string
> to an HTTP endpoint which decides that Xen build is good enough to
> allow it to be merged into our testing branch).
> 
> Overall there are a lot more possibilities than what I've put together
> so far. The coverage is not yet the same as Travis CI due to missing
> arm builds.

I took a peek at your patches and I am not an expert of GitLab but it 
all looks fine to me. You can add

Reviewed-by: Konrad Rzeszutek Wilk 

On them if you would like.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2 0/8] Using GitLab CI for build testing

[Doug Goldstein]

Really early work on switching over to using GitLab CI over
Travis CI. GitLab is a competitor to GitHub with some advantages
such as an integrated CI system with a lot more flexibility
and control. It additionally is fully open sourced unlike GitHub
and Travis CI. We can even run an instance if that is preferred
over using the hosted instance.

This change uses GitLab CI's ability to use Docker based runners
for running tests. With GitHub we also use a Docker based runner
but we are limited to one Docker container that is then morphed
a number of different ways. With this approach we can specify
different Docker containers for every run (or use the same). By
using different Docker containers we can build environments that
match systems where Xen can and should build. Using this
approach we should be able to cutdown on the number of surpise
build failures encountered by users.

Worth noting another advantage is that builders can be VMs or even
physical hosts as well. So we can have a FreeBSD VM that can be a
build environment.

Further more the above link is to a GitLab pipeline, pipelines are
made of stages which are further composed of jobs. Currently the
example uses one stage called build and all the different distros
are different jobs.  But there's a lot of flexibility as to what
can be done here. There can be stages that check code style or other
pre-flight checks that people may be interested. There can be stages
that happen after the build stage as well such as some simple tests
(e.g. I use it to run the just built xen.gz with an initramfs only
dom0 that contains a small Alpine Linux VM that spits out a string
to an HTTP endpoint which decides that Xen build is good enough to
allow it to be merged into our testing branch).

Overall there are a lot more possibilities than what I've put together
so far. The coverage is not yet the same as Travis CI due to missing
arm builds.

Example run: https://gitlab.com/cardoe/xen/pipelines/18968075
---
change since v1:
- added makefile to help build containers
- moved readme as the first patch
- moved from "cardoe" tenant to "xen-project"
- added debian:stretch
- added clang builds
- added debug y/n builds
- added maintainer info

Doug Goldstein (8):
  ci: add README and makefile for containers
  ci: add Dockerfile for CentOS 7.2
  ci: add Dockerfile for Ubuntu 14.04
  ci: add Dockerfile for Ubuntu 16.04
  ci: add Dockerfile for Debian jessie
  ci: add Dockerfile for Debian stretch
  ci: add cfg to use GitLab CI to build
  ci: add new bits to MAINTAINERS combine with Travis

 .gitlab-ci.yml | 164 ++-
 MAINTAINERS|  16 +-
 automation/build/Makefile  |  17 ++-
 automation/build/README.md |  34 +-
 automation/build/centos/7.2.dockerfile |  41 ++-
 automation/build/centos/CentOS-7.2.repo|  35 +-
 automation/build/debian/jessie.dockerfile  |  47 ++-
 automation/build/debian/stretch.dockerfile |  47 ++-
 automation/build/ubuntu/trusty.dockerfile  |  47 ++-
 automation/build/ubuntu/xenial.dockerfile  |  47 ++-
 10 files changed, 489 insertions(+), 6 deletions(-)
 create mode 100644 .gitlab-ci.yml
 create mode 100644 automation/build/Makefile
 create mode 100644 automation/build/README.md
 create mode 100644 automation/build/centos/7.2.dockerfile
 create mode 100644 automation/build/centos/CentOS-7.2.repo
 create mode 100644 automation/build/debian/jessie.dockerfile
 create mode 100644 automation/build/debian/stretch.dockerfile
 create mode 100644 automation/build/ubuntu/trusty.dockerfile
 create mode 100644 automation/build/ubuntu/xenial.dockerfile

base-commit: c0e34ba78aaec2e2b1aa2a810bc7b3ee1fdfcf3f
-- 
git-series 0.9.1

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel