On 28/01/2020 13.55, Alex Bennée wrote: > > Thomas Huth <th...@redhat.com> writes: > >> On 25/01/2020 19.31, Philippe Mathieu-Daudé wrote: >>> The NAME variable can be used to describe nicely a job (see [*]). >>> As we currently have 32 jobs, use it. This helps for quickly >>> finding a particular job. >>> >>> before: https://travis-ci.org/qemu/qemu/builds/639887646 >>> after: https://travis-ci.org/philmd/qemu/builds/641795043 >> >> Very good idea, correlating a job in the GUI to an entry in the yml file >> was really a pain, so far. >> >>> [*] >>> https://docs.travis-ci.com/user/customizing-the-build/#naming-jobs-within-matrices >>> >>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >>> --- >>> .travis.yml | 101 ++++++++++++++++++++++++++++++++++------------------ >>> 1 file changed, 67 insertions(+), 34 deletions(-) >>> >>> diff --git a/.travis.yml b/.travis.yml >>> index 6c1038a0f1..d68e35a2c5 100644 >>> --- a/.travis.yml >>> +++ b/.travis.yml >>> @@ -94,24 +94,28 @@ after_script: >>> >>> matrix: >>> include: >>> - - env: >>> + - name: "[x86] GCC static (user)" >> >> Could you please drop the [x86] and other architectures from the names? >> Travis already lists the build architecture in the job status page, so >> this information is redundant. > > Hmm for me the Travis page mis-renders the architecture (on firefox) so > I do find the arch in the text fairly handy.
That's really weird, I'm also using Firefox and it looks fine here! >>> # Alternate coroutines implementations are only really of interest to >>> KVM users >>> # However we can't test against KVM on Travis so we can only run unit >>> tests >>> - - env: >>> + - name: "[x86] check-unit coroutine=ucontext" >>> + env: >>> - CONFIG="--with-coroutine=ucontext --disable-tcg" >>> - TEST_CMD="make check-unit -j3 V=1" >>> >>> >>> - - env: >>> + - name: "[x86] check-unit coroutine=sigaltstack" >>> + env: >>> - CONFIG="--with-coroutine=sigaltstack --disable-tcg" >>> - TEST_CMD="make check-unit -j3 V=1" >>> >> >> Off-topic to your patch, but aren't coroutines something that is only >> used in the softmmu targets? If so, we could add --disable-user to the >> above two builds to speed things up a little bit. > > I think --disable-tcg implies --disable-user as you can't run without > it. D'oh, of course you're right, --disable-tcg limits the targets to *86-softmmu! Thomas
