On Fri, 27 Jan 2023 at 12:39, Kevin Wolf wrote:
> If it worked well enough for Stefan, I think it would be worth trying to
> batch some pull requests going forward. What is the downside of it? If
> CI fails and flaky tests seem to be at fault, I assume you just re-run
> the job, no matter whether
On Fri, 27 Jan 2023 at 13:11, Peter Maydell wrote:
>
> On Fri, 27 Jan 2023 at 12:39, Kevin Wolf wrote:
> >
> > Am 26.01.2023 um 15:28 hat Peter Maydell geschrieben:
> > > On Thu, 26 Jan 2023 at 14:25, Stefan Hajnoczi wrote:
> > > >
> > > > Are you batching pull requests? I used that approach las
On Fri, 27 Jan 2023 at 12:39, Kevin Wolf wrote:
>
> Am 26.01.2023 um 15:28 hat Peter Maydell geschrieben:
> > On Thu, 26 Jan 2023 at 14:25, Stefan Hajnoczi wrote:
> > >
> > > Are you batching pull requests? I used that approach last release
> > > cycle. CI takes so long to run that I didn't want
On Fri, Jan 27, 2023 at 01:39:08PM +0100, Kevin Wolf wrote:
> Am 26.01.2023 um 15:28 hat Peter Maydell geschrieben:
> > On Thu, 26 Jan 2023 at 14:25, Stefan Hajnoczi wrote:
> > >
> > > Are you batching pull requests? I used that approach last release
> > > cycle. CI takes so long to run that I did
Am 26.01.2023 um 15:28 hat Peter Maydell geschrieben:
> On Thu, 26 Jan 2023 at 14:25, Stefan Hajnoczi wrote:
> >
> > Are you batching pull requests? I used that approach last release
> > cycle. CI takes so long to run that I didn't want to run it for every
> > pull request. Batching worked well ov
On Thu, Jan 26, 2023 at 06:41:50PM +, Eldon Stegall wrote:
> As far as baremetal goes, I find authenticated IPXE scripts work well
> for a number of these scenarios, and permit very dynamic allocation of
> resources. I have been a fan of the ignition/coreos/fcos strategy for
> baremetal deploy
If this backpressure leads us to less waste of time & energy (close &
personal: faster make check), then I <3 gitlab!
Hi,
> Scratch that, it is actually possible to configure private runners
> to pick up un-tagged jobs
>
> https://docs.gitlab.com/ee/ci/runners/configure_runners.html#runner-is-allowed-to-run-untagged-jobs
>
> i'm not sure what the prioritization is between shared and private
> runners when us
On 26/01/2023 15.28, Peter Maydell wrote:
On Thu, 26 Jan 2023 at 14:25, Stefan Hajnoczi wrote:
Are you batching pull requests? I used that approach last release
cycle. CI takes so long to run that I didn't want to run it for every
pull request. Batching worked well overall.
No, I just do one
Thomas Huth writes:
> On 26/01/2023 15.41, Peter Maydell wrote:
>> On Thu, 26 Jan 2023 at 14:35, Daniel P. Berrangé wrote:
>>> I'm confident we can rationalize our jobs, especially the cross
>>> compilation ones.
>>>
>>> For each non-x86 arch we've got two sets of jobs, one for system
>>> emul
On 26/01/2023 15.41, Peter Maydell wrote:
On Thu, 26 Jan 2023 at 14:35, Daniel P. Berrangé wrote:
I'm confident we can rationalize our jobs, especially the cross
compilation ones.
For each non-x86 arch we've got two sets of jobs, one for system
emulators and one for user emulators.
IMHO the m
On Thu, 26 Jan 2023 at 14:35, Daniel P. Berrangé wrote:
> I'm confident we can rationalize our jobs, especially the cross
> compilation ones.
>
> For each non-x86 arch we've got two sets of jobs, one for system
> emulators and one for user emulators.
>
> IMHO the most interesting part of non-x86 t
On Thu, Jan 26, 2023 at 02:13:22PM +, Alex Bennée wrote:
>
> Eldon Stegall writes:
>
> > On Thu, Jan 26, 2023 at 01:22:32PM +, Peter Maydell wrote:
> >> Hi; we've run out of gitlab CI pipeline minutes for this month.
> >> This leaves us the choice of:
> >> (a) don't process any more pul
On Thu, Jan 26, 2023 at 01:57:02PM +, Alex Bennée wrote:
>
> Peter Maydell writes:
>
> > Hi; we've run out of gitlab CI pipeline minutes for this month.
> > This leaves us the choice of:
> > (a) don't process any more pullreqs til we get more minutes in Feb
> > (b) merge pullreqs blindly w
On Thu, Jan 26, 2023 at 02:18:23PM +, Daniel P. Berrangé wrote:
> On Thu, Jan 26, 2023 at 01:52:39PM +, Eldon Stegall wrote:
> > On Thu, Jan 26, 2023 at 01:22:32PM +, Peter Maydell wrote:
> > > Hi; we've run out of gitlab CI pipeline minutes for this month.
> > > This leaves us the choi
On Thu, 26 Jan 2023 at 14:25, Stefan Hajnoczi wrote:
>
> Are you batching pull requests? I used that approach last release
> cycle. CI takes so long to run that I didn't want to run it for every
> pull request. Batching worked well overall.
No, I just do one test per pullreq. IME the CI is flaky
On Thu, 26 Jan 2023 at 14:16, Alex Bennée wrote:
> Eldon Stegall writes:
> > I have several baremetal machines colocated that I could dedicate to
> > execute these runs, dual processor xeons with a couple hundred gigs of
> > RAM. I would need approx 48 hours notice to initially provision the
> >
On Thu, Jan 26, 2023 at 11:07:37AM -0300, Daniel Henrique Barboza wrote:
>
>
> On 1/26/23 10:57, Alex Bennée wrote:
> >
> > Peter Maydell writes:
> >
> > > Hi; we've run out of gitlab CI pipeline minutes for this month.
> > > This leaves us the choice of:
> > > (a) don't process any more pul
Are you batching pull requests? I used that approach last release
cycle. CI takes so long to run that I didn't want to run it for every
pull request. Batching worked well overall.
You could try the apply-pullreq --apply-many option in the modified
script I sent in on Wed, 14 Dec 2022.
The workfl
On Thu, Jan 26, 2023 at 01:52:39PM +, Eldon Stegall wrote:
> On Thu, Jan 26, 2023 at 01:22:32PM +, Peter Maydell wrote:
> > Hi; we've run out of gitlab CI pipeline minutes for this month.
> > This leaves us the choice of:
> > (a) don't process any more pullreqs til we get more minutes in F
Eldon Stegall writes:
> On Thu, Jan 26, 2023 at 01:22:32PM +, Peter Maydell wrote:
>> Hi; we've run out of gitlab CI pipeline minutes for this month.
>> This leaves us the choice of:
>> (a) don't process any more pullreqs til we get more minutes in Feb
>> (b) merge pullreqs blindly withou
On 1/26/23 10:57, Alex Bennée wrote:
Peter Maydell writes:
Hi; we've run out of gitlab CI pipeline minutes for this month.
This leaves us the choice of:
(a) don't process any more pullreqs til we get more minutes in Feb
(b) merge pullreqs blindly without CI testing
(c) buy more minut
Peter Maydell writes:
> Hi; we've run out of gitlab CI pipeline minutes for this month.
> This leaves us the choice of:
> (a) don't process any more pullreqs til we get more minutes in Feb
> (b) merge pullreqs blindly without CI testing
> (c) buy more minutes
>
> For the moment I propose to
On Thu, Jan 26, 2023 at 01:22:32PM +, Peter Maydell wrote:
> Hi; we've run out of gitlab CI pipeline minutes for this month.
> This leaves us the choice of:
> (a) don't process any more pullreqs til we get more minutes in Feb
> (b) merge pullreqs blindly without CI testing
> (c) buy more min
Hi; we've run out of gitlab CI pipeline minutes for this month.
This leaves us the choice of:
(a) don't process any more pullreqs til we get more minutes in Feb
(b) merge pullreqs blindly without CI testing
(c) buy more minutes
For the moment I propose to take option (a). My mail filter will
co
25 matches
Mail list logo
