Re: [PATCH v2 2/2] gitlab-ci: add an ARM32 qemu-based smoke test

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 18 Mar 2022, Anthony PERARD wrote:
> On Wed, Mar 16, 2022 at 06:46:53PM -0700, Stefano Stabellini wrote:
> > +curl -fsSLO 
> > http://http.us.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/vmlinuz
> > +curl -fsSLO 
> > http://http.us.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/initrd.gz
> 
>     curl --fail --silent --show-error --location --remote-name
> 
> I didn't know what all those short options were, I had to write it
> down. In script to be shared with others, I think it's better to use the
> long options, as it's kind of self-documenting.
> 
> Now, there an issue with the command line, "--remote-name" (or -O) needs
> to be replaced. We don't care about how the server calls the file, it is
> much more important do know where it is going to be stored. Instead, you
> should use "--output" to write the file to the location the script is
> going to use. It happened to work now, but we don't have to trust
> the Internet when not needed.
> 

Sure I copy-pasted it from the other scripts. With your suggestion it
becomes:
curl --fail --silent --show-error --location --remote-name 
http://http.us.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/vmlinuz

I can make the change


> Also, maybe use "https"?

https doesn't work for this:

$ curl --fail --silent --show-error --location --remote-name 
https://http.us.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/vmlinuz
curl: (60) SSL: no alternative certificate subject name matches target host 
name 'http.us.debian.org'


> Also, maybe as an improvement for later, and to avoid having to rely on
> the Internet, we could probably store those artifacts in the container
> that's going to run the test. But I'm not asking this for now.

I agree! Even better if we could update the kernel too. I think for now
it is OK but I'll try to improve it in the following weeks.


> > +timeout -k 1 240 \
> > +./qemu-system-arm \
> 
> There's probably a better way than waiting for the "timeout" like running an
> "init" that print something and shutdown the machine. But I guess
> that's ok for now.

Yeah I agree on both points. The other 3 tests are in the same
situation.