Updating CI-runners to buster

Updating CI-runners to buster

[vijai kumar]

[-- Attachment #1.1: Type: text/plain, Size: 504 bytes --]

Hi Baurzhan,

Looks like the build_task.sh wrapper we have in 
http://ci.isar-build.org:8080 still uses stretch environment
for build. Can we update this to buster?

My CI builds with my latest patches[1] for deb-src caching are failing 
because of a bug[2] in the reprepro in stretch.

http://ci.isar-build.org:8080/job/isar_vkk_devel/34/console

[1] https://groups.google.com/d/msg/isar-users/R45XPq1r3wA/TBHINrLmFwAJ
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854480

Thanks,
Vijai Kumar K

[-- Attachment #1.2: Type: text/html, Size: 695 bytes --]

Re: Updating CI-runners to buster

[Baurzhan Ismagulov]

Hello Vijai Kumar,

On Thu, Feb 13, 2020 at 10:01:53PM -0800, vijai kumar wrote:
> Looks like the build_task.sh wrapper we have in 
> http://ci.isar-build.org:8080 still uses stretch environment
> for build. Can we update this to buster?

Yes, I had installed a new server but encountered issues with configuration
migration, so that got stalled :( . I'll have a look again and let you know in
the next days.

With kind regards,
Baurzhan.

Re: Updating CI-runners to buster

[vijai kumar]

[-- Attachment #1.1: Type: text/plain, Size: 644 bytes --]

NP Baurzhan. Please do let us know once it is upgraded :)

Thanks,
Vijai Kumar K

On Monday, February 17, 2020 at 11:37:40 AM UTC+5:30, Baurzhan Ismagulov 
wrote:
>
> Hello Vijai Kumar, 
>
> On Thu, Feb 13, 2020 at 10:01:53PM -0800, vijai kumar wrote: 
> > Looks like the build_task.sh wrapper we have in 
> > http://ci.isar-build.org:8080 still uses stretch environment 
> > for build. Can we update this to buster? 
>
> Yes, I had installed a new server but encountered issues with 
> configuration 
> migration, so that got stalled :( . I'll have a look again and let you 
> know in 
> the next days. 
>
> With kind regards, 
> Baurzhan. 
>

[-- Attachment #1.2: Type: text/html, Size: 1307 bytes --]

Re: Updating CI-runners to buster

[Baurzhan Ismagulov]

Hello Vijai Kumar,

On Mon, Feb 17, 2020 at 10:10:13PM -0800, vijai kumar wrote:
> NP Baurzhan. Please do let us know once it is upgraded :)

I've moved the service, please check http://ci.isar-build.org:8080/. There are
still a couple of glitches, but the main stuff seems to work. Please let me
know if there are any issues.

With kind regards,
Baurzhan.

Re: Updating CI-runners to buster

[vijai kumar]

[-- Attachment #1.1: Type: text/plain, Size: 543 bytes --]



On Monday, February 24, 2020 at 7:47:04 PM UTC+5:30, Baurzhan Ismagulov 
wrote:
>
> Hello Vijai Kumar, 
>
> On Mon, Feb 17, 2020 at 10:10:13PM -0800, vijai kumar wrote: 
> > NP Baurzhan. Please do let us know once it is upgraded :) 
>
> I've moved the service, please check http://ci.isar-build.org:8080/. 
> There are 
> still a couple of glitches, but the main stuff seems to work. Please let 
> me 
> know if there are any issues. 
>

Thank you Baurzhan. I will give it a try.

Best,
Vijai Kumar K 


> With kind regards, 
> Baurzhan. 
>

[-- Attachment #1.2: Type: text/html, Size: 1376 bytes --]

Re: Updating CI-runners to buster

[Henning Schild]

Hi,

i think we can now enable the two arm64 CI jobs that are currently
commented out to cater for old CI runners.

Henning 

On Mon, 24 Feb 2020 15:16:58 +0100
Baurzhan Ismagulov <ibr@radix50.net> wrote:

> Hello Vijai Kumar,
> 
> On Mon, Feb 17, 2020 at 10:10:13PM -0800, vijai kumar wrote:
> > NP Baurzhan. Please do let us know once it is upgraded :)  
> 
> I've moved the service, please check http://ci.isar-build.org:8080/.
> There are still a couple of glitches, but the main stuff seems to
> work. Please let me know if there are any issues.
> 
> With kind regards,
> Baurzhan.
> 

Re: Updating CI-runners to buster

[Baurzhan Ismagulov]

On Tue, Mar 10, 2020 at 02:59:46PM +0100, Henning Schild wrote:
> i think we can now enable the two arm64 CI jobs that are currently
> commented out to cater for old CI runners.

Makes sense. Then, I'd suggest to drop stretch host support. Opinions?

With kind regards,
Baurzhan.

Re: Updating CI-runners to buster

[Henning Schild]

On Tue, 10 Mar 2020 18:54:52 +0100
Baurzhan Ismagulov <ibr@radix50.net> wrote:

> On Tue, Mar 10, 2020 at 02:59:46PM +0100, Henning Schild wrote:
> > i think we can now enable the two arm64 CI jobs that are currently
> > commented out to cater for old CI runners.  
> 
> Makes sense. Then, I'd suggest to drop stretch host support. Opinions?

What does dropping mean? I would keep it alive as long as possible,
especially while stretch is still alive. For the CI runners and all
possible targets i.e. buster arm64 we can drop it.

Henning

> With kind regards,
> Baurzhan.
> 

Re: Updating CI-runners to buster

[Baurzhan Ismagulov]

On Wed, Mar 11, 2020 at 09:28:29AM +0100, Henning Schild wrote:
> > > i think we can now enable the two arm64 CI jobs that are currently
> > > commented out to cater for old CI runners.  
> > 
> > Makes sense. Then, I'd suggest to drop stretch host support. Opinions?
> 
> What does dropping mean? I would keep it alive as long as possible,
> especially while stretch is still alive. For the CI runners and all
> possible targets i.e. buster arm64 we can drop it.

By "dropping stretch host support" I meant (option 1):

1. Remove Jenkins jobs building on stretch:

   1. isar_master_stretch
   2. isar_master_stretch_fast
   3. isar_next_stretch
   4. isar_next_stretch_fast

2. Keep building all targets as defined in scripts/ci_build.sh next ad81c98.
   Add qemuarm64-buster and qemuarm64-bullseye.


I understand your suggestion as follows (option 2):

1. Keep Jenkins stretch builders (as above, {master,next}_stretch[_fast]).

2. Add qemuarm64-{buster,bullseye} targets for buster builders but not for
   the stretch ones.

Is this what you mean?


I would support proceeding with option #2.


With kind regards,
Baurzhan.

Re: Updating CI-runners to buster

[Henning Schild]

On Wed, 11 Mar 2020 11:37:30 +0100
Baurzhan Ismagulov <ibr@radix50.net> wrote:

> On Wed, Mar 11, 2020 at 09:28:29AM +0100, Henning Schild wrote:
> > > > i think we can now enable the two arm64 CI jobs that are
> > > > currently commented out to cater for old CI runners.    
> > > 
> > > Makes sense. Then, I'd suggest to drop stretch host support.
> > > Opinions?  
> > 
> > What does dropping mean? I would keep it alive as long as possible,
> > especially while stretch is still alive. For the CI runners and all
> > possible targets i.e. buster arm64 we can drop it.  
> 
> By "dropping stretch host support" I meant (option 1):
> 
> 1. Remove Jenkins jobs building on stretch:
> 
>    1. isar_master_stretch
>    2. isar_master_stretch_fast
>    3. isar_next_stretch
>    4. isar_next_stretch_fast
> 
> 2. Keep building all targets as defined in scripts/ci_build.sh next
> ad81c98. Add qemuarm64-buster and qemuarm64-bullseye.
> 
> 
> I understand your suggestion as follows (option 2):
> 
> 1. Keep Jenkins stretch builders (as above,
> {master,next}_stretch[_fast]).
> 
> 2. Add qemuarm64-{buster,bullseye} targets for buster builders but
> not for the stretch ones.
> 
> Is this what you mean?
> 
> 
> I would support proceeding with option #2.

Seems you are just thinking about which combinations to actually test
in CI. I think dropping stretch hosts from the official testing is no
problem.
You said "dropping stretch host support" which to me sounded like
actually removing code or allowing code that means hosts will have to
be >=buster.

Dropping tests is OK, dropping support is not. Of cause testing ensures
support, but i would hope that the risk of a breakage is low.

Henning

> 
> With kind regards,
> Baurzhan.
> 

Re: Updating CI-runners to buster

[Baurzhan Ismagulov]

On Wed, Mar 11, 2020 at 12:30:23PM +0100, Henning Schild wrote:
> Seems you are just thinking about which combinations to actually test
> in CI. I think dropping stretch hosts from the official testing is no
> problem.
> You said "dropping stretch host support" which to me sounded like
> actually removing code or allowing code that means hosts will have to
> be >=buster.
> 
> Dropping tests is OK, dropping support is not. Of cause testing ensures
> support, but i would hope that the risk of a breakage is low.

If stretch host support is desired (which I second), then we should ensure that
patches breaking it don't go in (or are handled appropriately depending on the
host version) => we should continue testing stretch hosts.

I'll check what that means for the CI.

With kind regards,
Baurzhan.