[ovs-dev] [RFC] OVS robot discussion - check API integration

Aaron Conole aconole at redhat.com
Wed Feb 13 16:56:57 UTC 2019


Ilya Maximets <i.maximets at samsung.com> writes:

> On 11.02.2019 18:24, Aaron Conole wrote:
>> I'm following up on a discussion where we briefly talked about adding
>> a 'check' to OVS patch series during the OVS Conference.  'Check' is
>> what the patchwork project provides to show that certain tests have been
>> performed.  It is made up of a name, a status, and a URL.  Some of the
>> projects in the ozlabs patchwork instance are using the check feature
>> already, so there's some examples to reference.
>> 
>> My idea is to push some data into travis / cirrus that can be used to
>> insert a check against a patch series.  This would allow committers to
>> look at the status page on patchwork and see at a glance the links to
>> the travis, and if a robot email was sent.
>> 
>> The naivest way I can think of getting these results published is by
>> modifying ${OS}-build.sh like:
>> 
>> ---
>> diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
>> index 0a2091061..38359c86f 100755
>> --- a/.travis/linux-build.sh
>> +++ b/.travis/linux-build.sh
>> @@ -8,6 +8,47 @@ SPARSE_FLAGS=""
>>  EXTRA_OPTS=""
>>  TARGET="x86_64-native-linuxapp-gcc"
>>  
>> +function start_patchwork_check()
>> +{
>> +    if [ ! -e ".git/config" ]; then
>> +        return;
>> +    fi
>> +
>> +    if ! git branch | grep \\* | grep series_ >/dev/null; then
>> +        return;
>> +    fi
>> +
>> +    curl -s $PW_API_URL/$(SERIES_ID) ...submit check start ...
>> +}
>> +
>> +function bad_check_result()
>> +{
>> +    if [ ! -e ".git/config" ]; then
>> +        return;
>> +    fi
>> +
>> +    if ! git branch | grep \\* | grep series_ >/dev/null; then
>> +        return;
>> +    fi
>> +
>> +    curl -s $PW_API_URL/$(SERIES_ID) ...set check to bad...
>> +}
>> +
>> +function check_success()
>> +{
>> +    if [ ! -e ".git/config" ]; then
>> +        return;
>> +    fi
>> +
>> +    if ! git branch | grep \\* | grep series_ >/dev/null; then
>> +        return;
>> +    fi
>> +
>> +    curl -s $PW_API_URL/$(SERIES_ID) ...set check to success...
>> +}
>> +
>> +trap '[ "$?" -eq 0 ] || bad_check_result' INT ERR TERM
>> +
>>  function install_kernel()
>>  {
>>      if [[ "$1" =~ ^4.* ]]; then
>> ---
>> 
>> I think this could work.  We can use the travis "encrypted info" data to
>> push the credentials but that probably needs to be encrypted for the
>> robot key.  It does put some kind of pollution in the travis / cirrus
>> builds (because 'series_*' appears nowhere in the official repository).
>> Maybe that isn't acceptable.
>> 
>> I am planning to follow the guidebook at
>> https://docs.travis-ci.com/user/environment-variables/#defining-variables-in-repository-settings
>> and store the credentials variables for just the OVS robot repo.
>> 
>> Maybe there's another opinion.  Probably there's a better way of
>> sending the data around, sharing credentials, or passing requests so
>> that other projects can also integrate.  Thoughts, opinions, comments?
>
> I don't know if it could be an issue, but I just wanted to warn about
> 'set -x' that we have now in a Travis scripts. You need to be careful
> with exported credentials.

Keen observation!

> And we, actually, already have special ovs-build mail-list. It could
> be used if you'll decide to choose DPDK way of working with patchwork.

It looks intriguing.  I like the idea that anyone could then contribute
'check results' to the patchwork project.  But, it seems like it would
require some additional infrastructure.  We would need a script that
will periodically run against the list, or possibly an alias that is
subscribed to the list that is just an alias to
/bin/process_ovs_build_mails.sh that can update the check interface.

> Best regards, Ilya Maximets.


More information about the dev mailing list