[LTP] [PATCH v7 2/4] ci: add patchwork communication script

[Andrea Cervesato]

Hi Petr,

this is exactly the reason why I prefer "set -e" (I'm not a shell script 
expert anyway...). But I was actually thinking that the whole pipe 
command will fail with !=0 ret code anyway, since any curl output which 
is not a REST API reply (JSON string in particular) and having the right 
format, will cause jq to fail. So the first implementation is 
technically working. I would like to keep that simple and check $? later 
on after the piped command as it was before. Let me know what you think.

- Andrea

On 4/15/25 19:35, Petr Vorel wrote:
> Hi Andrea,
>
> ...
>> +fetch_series() {
>> +        local current_time=$(date +%s)
>> +        local since_time=$(expr $current_time - $PATCHWORK_SINCE)
>> +        local date=$(date -u -d @$since_time +"%Y-%m-%dT%H:%M:%SZ")
>> +        local stdout=$(curl -k -G "$PATCHWORK_URL/api/events/" \
>> +                --data "category=series-completed" \
>> +                --data "project=ltp" \
>> +                --data "state=new" \
>> +                --data "since=$date" \
>> +                --data "archive=no")
>> +
>> +        [ $? -eq 0 ] || exit 1
> You may have noticed in tst_test.sh, that local variable never uses $(...).
> It assign single value, but never call $(...). This is for a reason.
>
> Try:
>
> $ cat foo.sh
> #!/bin/sh
>
> foo()
> {
>      local foo=$(aasfd_command_which_fails)
>
>      [ $? -eq 0 ] || exit 1
>      echo "run after"
> }
>
> bar()
> {
>      local foo
>
>      foo=$(aasfd_command_which_fails)
>
>      [ $? -eq 0 ] || exit 1
>      echo "will not run after"
> }
>
> foo
> bar
>
> ---
> $ bash ./foo.sh
> ./foo.sh: line 5: aasfd_command_which_fails: command not found
> run after
> ./foo.sh: line 15: aasfd_command_which_fails: command not found
>
> What happen? $? is assigned from result of local keyword,
> it overwrite previous result from $(...). Note even '#!/bin/sh -e'
> would not cause it to fail early.
>
> (Deliberately test with bash to demonstrate local behaves oddly not even in dash
> or 'busybox sh' but even with bash. And yes, given how many errors we caught
> with this script and generate_arch.sh and generate_syscalls.sh due shell strange
> syntax and behavior makes me wonder if we really want to use shell scripts for
> anything longer than 5 lines.)
>
> Kind regards,
> Petr