[PATCH v2 0/5] Move remaining x86 Travis jobs to the gitlab-CI

Thomas Huth posted 5 patches 3 years, 3 months ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20210205091857.845389-1-thuth@redhat.com
Maintainers: "Philippe Mathieu-Daudé" <philmd@redhat.com>, Wainer dos Santos Moschetta <wainersm@redhat.com>, Fam Zheng <fam@euphon.net>, Thomas Huth <thuth@redhat.com>, "Alex Bennée" <alex.bennee@linaro.org>
There is a newer version of this series
.gitlab-ci.yml                             |  38 ++++++-
.travis.yml                                | 111 ---------------------
MAINTAINERS                                |   2 +-
scripts/{travis => ci}/coverage-summary.sh |   2 +-
tests/docker/dockerfiles/ubuntu2004.docker |   2 +
5 files changed, 39 insertions(+), 116 deletions(-)
rename scripts/{travis => ci}/coverage-summary.sh (92%)
[PATCH v2 0/5] Move remaining x86 Travis jobs to the gitlab-CI
Posted by Thomas Huth 3 years, 3 months ago
Since Travis changed their policies, travis-ci.org will soon become
completely useless for the QEMU project. We should now really make sure
that we move the remaining tests as good as possible to the gitlab-CI
instead.

v2:
 - Run "make check" in the gprof/gcov test
 - Make sure that we run at least one test with --enable-debug
 - Reworked the thread sanitizer patch to use --enable-tsan + clang now

Philippe Mathieu-Daudé (1):
  travis.yml: Move gprof/gcov test across to gitlab

Thomas Huth (4):
  travis.yml: Move the -fsanitize=undefined test to the gitlab-CI
  travis.yml: Move the --enable-modules test to the gitlab-CI
  travis.yml: (Re-)move the --enable-debug jobs
  travis.yml: Move the -fsanitize=thread testing to the gitlab-CI

 .gitlab-ci.yml                             |  38 ++++++-
 .travis.yml                                | 111 ---------------------
 MAINTAINERS                                |   2 +-
 scripts/{travis => ci}/coverage-summary.sh |   2 +-
 tests/docker/dockerfiles/ubuntu2004.docker |   2 +
 5 files changed, 39 insertions(+), 116 deletions(-)
 rename scripts/{travis => ci}/coverage-summary.sh (92%)

-- 
2.27.0


Re: [PATCH v2 0/5] Move remaining x86 Travis jobs to the gitlab-CI
Posted by Alex Bennée 3 years, 3 months ago
Thomas Huth <thuth@redhat.com> writes:

> Since Travis changed their policies, travis-ci.org will soon become
> completely useless for the QEMU project. We should now really make sure
> that we move the remaining tests as good as possible to the gitlab-CI
> instead.

Queued to testing/next, thanks.

-- 
Alex Bennée

Re: [PATCH v2 0/5] Move remaining x86 Travis jobs to the gitlab-CI
Posted by Thomas Huth 3 years, 3 months ago
On 09/02/2021 21.37, Alex Bennée wrote:
> 
> Thomas Huth <thuth@redhat.com> writes:
> 
>> Since Travis changed their policies, travis-ci.org will soon become
>> completely useless for the QEMU project. We should now really make sure
>> that we move the remaining tests as good as possible to the gitlab-CI
>> instead.
> 
> Queued to testing/next, thanks.

Thanks, but please unqueue them again, I still want to send a v3 to address 
your comment on the -fsanitize=undefined patch... and I also noticed that 
the gprof/gcov job runs very long and sometimes hits the 1h time limit, so I 
need to revisit the set of target architectures there...

  Thomas


Re: [PATCH v2 0/5] Move remaining x86 Travis jobs to the gitlab-CI
Posted by Alex Bennée 3 years, 3 months ago
Will do.

On Wed, 10 Feb 2021, 05:44 Thomas Huth, <thuth@redhat.com> wrote:

> On 09/02/2021 21.37, Alex Bennée wrote:
> >
> > Thomas Huth <thuth@redhat.com> writes:
> >
> >> Since Travis changed their policies, travis-ci.org will soon become
> >> completely useless for the QEMU project. We should now really make sure
> >> that we move the remaining tests as good as possible to the gitlab-CI
> >> instead.
> >
> > Queued to testing/next, thanks.
>
> Thanks, but please unqueue them again, I still want to send a v3 to
> address
> your comment on the -fsanitize=undefined patch... and I also noticed that
> the gprof/gcov job runs very long and sometimes hits the 1h time limit, so
> I
> need to revisit the set of target architectures there...
>
>   Thomas
>
>