[PATCH 2/2] gitlab-ci: Test Fedora capstone package

Philippe Mathieu-Daudé posted 2 patches 4 years, 9 months ago
[PATCH 2/2] gitlab-ci: Test Fedora capstone package
Posted by Philippe Mathieu-Daudé 4 years, 9 months ago
Test building the 4 targets using the capstone disassembler
with the capstone package provided on Fedora.

Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
---
 .gitlab-ci.yml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index de3a3d25b58..913940656de 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -493,6 +493,13 @@ build-tci:
     - QTEST_QEMU_BINARY="./qemu-system-x86_64" ./tests/qtest/pxe-test
     - QTEST_QEMU_BINARY="./qemu-system-s390x" ./tests/qtest/pxe-test -m slow
 
+build-capstone-distrib:
+  <<: *native_build_job_definition
+  variables:
+    IMAGE: fedora
+    CONFIGURE_ARGS: --enable-capstone=system --disable-tools --disable-docs
+    TARGETS: arm-softmmu ppc-softmmu x86_64-linux-user s390x-linux-user
+
 # Alternate coroutines implementations are only really of interest to KVM users
 # However we can't test against KVM on Gitlab-CI so we can only run unit tests
 build-coroutine-ucontext:
-- 
2.26.2

Re: [PATCH 2/2] gitlab-ci: Test Fedora capstone package
Posted by Daniel P. Berrangé 4 years, 9 months ago
On Tue, Jan 26, 2021 at 12:36:49PM +0100, Philippe Mathieu-Daudé wrote:
> Test building the 4 targets using the capstone disassembler
> with the capstone package provided on Fedora.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
> ---
>  .gitlab-ci.yml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index de3a3d25b58..913940656de 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -493,6 +493,13 @@ build-tci:
>      - QTEST_QEMU_BINARY="./qemu-system-x86_64" ./tests/qtest/pxe-test
>      - QTEST_QEMU_BINARY="./qemu-system-s390x" ./tests/qtest/pxe-test -m slow
>  
> +build-capstone-distrib:
> +  <<: *native_build_job_definition
> +  variables:
> +    IMAGE: fedora
> +    CONFIGURE_ARGS: --enable-capstone=system --disable-tools --disable-docs
> +    TARGETS: arm-softmmu ppc-softmmu x86_64-linux-user s390x-linux-user

Won't one of the existing jobs using Fedora automatically enable use
of the system capstone ?  I don't think we want to keep adding jobs
for each new possible configure arg. Instead try to re-use existing
jobs whereever possible.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|


Re: [PATCH 2/2] gitlab-ci: Test Fedora capstone package
Posted by Philippe Mathieu-Daudé 4 years, 9 months ago
On 1/26/21 12:39 PM, Daniel P. Berrangé wrote:
> On Tue, Jan 26, 2021 at 12:36:49PM +0100, Philippe Mathieu-Daudé wrote:
>> Test building the 4 targets using the capstone disassembler
>> with the capstone package provided on Fedora.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>>  .gitlab-ci.yml | 7 +++++++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index de3a3d25b58..913940656de 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -493,6 +493,13 @@ build-tci:
>>      - QTEST_QEMU_BINARY="./qemu-system-x86_64" ./tests/qtest/pxe-test
>>      - QTEST_QEMU_BINARY="./qemu-system-s390x" ./tests/qtest/pxe-test -m slow
>>  
>> +build-capstone-distrib:
>> +  <<: *native_build_job_definition
>> +  variables:
>> +    IMAGE: fedora
>> +    CONFIGURE_ARGS: --enable-capstone=system --disable-tools --disable-docs
>> +    TARGETS: arm-softmmu ppc-softmmu x86_64-linux-user s390x-linux-user
> 
> Won't one of the existing jobs using Fedora automatically enable use
> of the system capstone ?  I don't think we want to keep adding jobs
> for each new possible configure arg. Instead try to re-use existing
> jobs whereever possible.

I looked but couldn't find one. Eventually the TCI job.

As this is unlikely to fail often, I'll see with Thomas the other
possible policies. Building this every month/release should be enough.