Re: [PATCH v1] automation: provide example for downloading an existing container

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 16 May 2023, Olaf Hering wrote:
> Am Mon, 15 May 2023 16:03:01 -0700 (PDT)
> schrieb Stefano Stabellini <sstabellini@xxxxxxxxxx>:
> 
> > Given that opensuse-tumbleweed is still broken (doesn't complete the
> > Xen build successfully) even after these patches, I suggest we use a
> > different example?
> 
> I think the example in automation/build/README.md needs to be fixed.
> Right now it does something different than the Gitlab CI.
> 
> The CI runs automation/scripts/build with some environment variables
> set, the example runs automation/scripts/containerize.
 
I think you have a point that automation/build/README.md should also
describe how to do what gitlab-ci does but locally (i.e. call
automation/scripts/build). It should not only describe
automation/scripts/containerize.

 
> For me qemu-xen builds, I assume it is supposed to be 'master ==
> "8c51cd9705 (HEAD -> dummy, origin/staging, origin/master, origin/HEAD,
> master) hw/xen/xen_pt: fix uninitialized variable", but we do not know
> what GI tests, because scripts/git-checkout.sh does not show what HEAD
> actually is. I think it needs to run "$GIT --no-pager log --oneline
> -n1" at the end, so everyone knows what 'dummy' actually is.

Gitlab-ci only runs automation/scripts/build which builds QEMU as part
of a regular Xen build.

If you want to see details of a failure:
https://gitlab.com/xen-project/xen/-/jobs/4284741849

---
In file included from 
/builds/xen-project/xen/tools/qemu-xen-dir-remote/include/qemu/coroutine.h:18,
                 from 
/builds/xen-project/xen/tools/qemu-xen-dir-remote/include/block/aio.h:20,
                 from ../qemu-xen-dir-remote/util/async.c:28:
../qemu-xen-dir-remote/util/async.c: In function 'aio_bh_poll':
/builds/xen-project/xen/tools/qemu-xen-dir-remote/include/qemu/queue.h:303:22: 
error: storing the address of local variable 'slice' in 
'*ctx.bh_slice_list.sqh_last' [-Werror=dangling-pointer=]
  303 |     (head)->sqh_last = &(elm)->field.sqe_next;                          
\
      |     ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
../qemu-xen-dir-remote/util/async.c:161:5: note: in expansion of macro 
'QSIMPLEQ_INSERT_TAIL'
  161 |     QSIMPLEQ_INSERT_TAIL(&ctx->bh_slice_list, &slice, next);
      |     ^~~~~~~~~~~~~~~~~~~~
../qemu-xen-dir-remote/util/async.c:156:17: note: 'slice' declared here
  156 |     BHListSlice slice;
      |                 ^~~~~
../qemu-xen-dir-remote/util/async.c:154:29: note: 'ctx' declared here
  154 | int aio_bh_poll(AioContext *ctx)
      |                 ~~~~~~~~~~~~^~~
cc1: all warnings being treated as errors
---

> I think it is perfectly fine that both examples refer to Tumbleweed,
> because one may need to fix future build errors, not test on something
> from which we already know that it works.

Sure I see your point. On the other hand Tumbleweed jobs are the ones
and only with "allow_failure". So among all the possible choices as
example, do we really need to pick the one and only that has been
failing for months? :-)