Hi,

As there was no new info on it from others, please enable continuous release, 
involving openQA.

Thanks,

Guillaume


Le 05/02/2019 à 15:37, Fabian Vogt a écrit :
Hi,

are there any news on this topic?
If not, I'll have to release the base container manually, which won't happen
regularly and also doesn't involve openQA.

Cheers,
Fabian

Am Donnerstag, 24. Januar 2019, 15:05:39 CET schrieb Guillaume Gardet:
-----Original Message-----
From: Fabian Vogt <fv...@suse.de>
Sent: 24 January 2019 14:54
To: opensuse-arm@opensuse.org
Cc: Guillaume Gardet <guillaume.gar...@arm.com>
Subject: Re: [opensuse-arm] Continuously rebuilt and tested Leap 15.1
images

Hi,

Am Donnerstag, 24. Januar 2019, 13:53:36 CET schrieb Guillaume Gardet:
-----Original Message-----
From: Fabian Vogt <fv...@suse.de>
Sent: 24 January 2019 13:44
To: Guillaume Gardet <guillaume.gar...@arm.com>
Cc: openSUSE ARM ML (opensuse-arm@opensuse.org) <opensuse-
a...@opensuse.org>
Subject: Re: [opensuse-arm] Continuously rebuilt and tested Leap
15.1 images

Hi,

Am Donnerstag, 24. Januar 2019, 13:24:41 CET schrieb Guillaume Gardet:
Hi,

-----Original Message-----
From: Fabian Vogt <fv...@suse.de>
Sent: 24 January 2019 12:07
To: openSUSE ARM ML (opensuse-arm@opensuse.org) <opensuse-
a...@opensuse.org>
Subject: [opensuse-arm] Continuously rebuilt and tested Leap
15.1 images

Hi,

For Leap 15.x on x86_64, images (Live media, JeOS and the base
container) are continuously rebuilt, tested and published in
openSUSE:Leap:15.x.
It's also the location the official opensuse/leap base image is
released from (into openSUSE:Containers:Leap:15.1).

Currently there is a similar project for :ARM at
openSUSE:Leap:15.1:ARM:Live, but it does not support
building/releasing after the main project is finalized and is
also not
coupled to openQA AFAICT.
Only ISO are tested in openQA, but images from
openSUSE:Leap:15.1:ARM:Live are pushed to
openSUSE:Leap:15.1:ARM:ToTest and released to download.o.o when
openQA is green.

The main difference is that decoupling ARM:Live from :ARM would
allow building, testing and releasing images built with updates after Gold.
True.
The only question would be: do we want to update ready to boot images
with latest leap software?
As we would not be able to test on real hardware.
I would say yes, simply because that's the same you would end up with after
using the Gold image and installing updates. It might be possible to put the
updated images in a different location though, so that the "known-working"
Gold images are still available.
It could be a solution, but we must not confuse our users with too much 
locations either.
Andreas, Dirk, any opinion?

As I'd like to have the base container setup the same for all
archs (continuous testing and updates is a requirement) it would
be very useful to use the same setup as x86_64 Leap. What's
missing is a subproject :ToTest with similiar config to
openSUSE:Leap:15.1:Images:ToTest and some mostly trivial changes
to
the totest-manager configuration.
It is never trivial with totest-manager configuration. 😉
The configuration is trivial - fixing bugs outside of the
configuration might not be :P
We already had hard time with Dirk to fix TW and Leap configs of ttm.
;)

It might also require some mapping changes inside OBS so that
the released images end up in the right location on
download.opensuse.org.
Once that's done, some openQA tests for the JeOS-EFI flavor
could be added and that would then also run the docker_ and
podman_image
tests.
I think the current layout would allow to test JeOS-EFI in openQA
already.
We would just need to add the proper filter to rsync.pl to push the
ISO to openQA.

Yes, but not independently from the main project.
True.

We need to setup new tests for JeOS-EFI as current JeOS tests do
not fit
JeOS-EFI (mainly because firstboot is disabled).

Yup, so we'd either need a test doing some configuration changes or
add jeos-firstboot to one of the images.
The best way would be to use a dedicated test which boot the real image,
enable firstboot, reboot, and perform tests afterwards.
Last time I checked firstboot, aarch64 TW did not show the same screens as
x86_64 TW.

That doesn't sound like a real-world scenario, so it doesn't make much sense
to do it that way IMO.
It could be. But the main  advantage with firstboot is to set-up data (user 
login and passwords, etc.) as expected by openQA.


Last question: would you be able to handle those changes? And fix
bugs, if any? ;)
I would take care of the rsync.pl and totest-manager changes - I can't change
anything in the :ARM project configuration.
I have no right on :ARM either. ;)

Cheers,
Guillaume


Cheers,
Fabian

Cheers,
Guillaume

Cheers,
Fabian

Cheers,
Guillaume

What do you think?

Thanks,
Fabian

--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
N�����r��y隊Z)z{.�櫛맲��r��z�^�ˬz��N�(�֜��^�       ޭ隊Z)z{.�櫛�0�������Ǩ�




--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Reply via email to