Hi Tim,
On Sat, Mar 05, 2022 at 12:52:39AM +0100, Tim Duesterhus wrote:
> Willy,
> Christopher,
>
> find a series that converts a few members of `struct proxy` into ists. All
> of them have already been converted into ists when operating on them, so
> directly storing them as ists makes that code
script/build-vtest.sh was/is reused for cirrus,travis
On Wed, Mar 9, 2022, 12:05 AM Tim Düsterhus wrote:
> William,
>
> On 3/8/22 16:06, William Lallemand wrote:
> > Let me know if we can improve the attached patch, otherwise I'll merge
> > it.
> >
>
> Let me make a competing proposal that:
>
>
William,
On 3/8/22 21:30, Tim Düsterhus wrote:
- The action is also easily reusable by other projects. For testing my
Adding to that: It's also easily reusable by the other workflows. We
currently have the separate musl.yml workflow that does this:
https://github.com/haproxy/haproxy/blob/5c
William,
On 3/8/22 20:54, William Lallemand wrote:
Honestly I'm confused, it is overcomplicated in my opinion :(
I don't really see the benefits in creating a whole new repository
instead of the few lines in the yaml file.
I believe that having a non-trivial amount of logic in a YAML file wil
On Tue, Mar 08, 2022 at 08:05:31PM +0100, Tim Düsterhus wrote:
>
> Let me make a competing proposal that:
>
> 1. Keeps the complexity out of the GitHub workflow configuration in
> haproxy/haproxy.
> 2. Still allows VTest caching.
>
> For my https://github.com/TimWolla/haproxy-auth-request repos
Willy,
On 3/8/22 20:11, Willy Tarreau wrote:
Yes my point was about VTest. However you made me think about a very good
reason for caching haproxy builds as well :-) Very commonly, some VTest
randomly fails. Timing etc are involved. And at the moment, it's impossible
to restart the tests without
Hi Thierry,
On Tue, Mar 08, 2022 at 08:23:20PM +0100, Thierry Fournier wrote:
>
> > On 8 Mar 2022, at 14:52, Willy Tarreau wrote:
> >
> > Hi guys,
> >
> > On Tue, Mar 08, 2022 at 01:46:50PM +, Marno Krahmer wrote:
> >> Hey Tim,
> >>
> >> I added a reference to the GitHub issue to the seco
> On 8 Mar 2022, at 14:52, Willy Tarreau wrote:
>
> Hi guys,
>
> On Tue, Mar 08, 2022 at 01:46:50PM +, Marno Krahmer wrote:
>> Hey Tim,
>>
>> I added a reference to the GitHub issue to the second line of the commit
>> message.
>
> Too late, I took the one you posted on the issue and tha
On Tue, Mar 08, 2022 at 04:40:40PM +0100, Tim Düsterhus wrote:
> > > Please don't. You always want to run a clean build, otherwise you're going
> > > to get super-hard-to-debug failures if some object file is accidentally
> > > taken from the cache instead of a clean build.
> >
> > What risk are y
William,
On 3/8/22 16:06, William Lallemand wrote:
Let me know if we can improve the attached patch, otherwise I'll merge
it.
Let me make a competing proposal that:
1. Keeps the complexity out of the GitHub workflow configuration in
haproxy/haproxy.
2. Still allows VTest caching.
For my h
On Tue, Mar 08, 2022 at 04:17:00PM +0100, Tim Düsterhus wrote:
> William
>
> On 3/8/22 16:06, William Lallemand wrote:
> > Also, I'm wondering if we could also cache the build of HAProxy, you
> > could think that weird, but in fact it will help relaunch the tests when
> > one is failing, without r
вт, 8 мар. 2022 г. в 21:13, William Lallemand :
> On Tue, Mar 08, 2022 at 08:38:00PM +0500, Илья Шипицин wrote:
> >
> > I'm fine with swapping "vtest" <--> "haproxy" order.
> >
>
> Ok, I can do that.
>
> > also, I do not think current patch is ugly, it is acceptable for me (if
> we
> > agree to sa
On Tue, Mar 08, 2022 at 08:38:00PM +0500, Илья Шипицин wrote:
>
> I'm fine with swapping "vtest" <--> "haproxy" order.
>
Ok, I can do that.
> also, I do not think current patch is ugly, it is acceptable for me (if we
> agree to save 8 sec).
Honestly I don't see the value in building the same b
Willy,
On 3/8/22 16:24, Willy Tarreau wrote:
Hi Tim,
On Tue, Mar 08, 2022 at 04:17:00PM +0100, Tim Düsterhus wrote:
William
On 3/8/22 16:06, William Lallemand wrote:
Also, I'm wondering if we could also cache the build of HAProxy, you
could think that weird, but in fact it will help relaunch
I thought to build "vtest" just once and deliver using artifacts to all
jobs. It will save some electricity, also GitHub sometimes throw 429 when
we download "vtest" in too many parallel ways.
however, it will not speed up, so I postoned that idea (something like that
https://docs.github.com/en/act
Hi Tim,
On Tue, Mar 08, 2022 at 04:17:00PM +0100, Tim Düsterhus wrote:
> William
>
> On 3/8/22 16:06, William Lallemand wrote:
> > Also, I'm wondering if we could also cache the build of HAProxy, you
> > could think that weird, but in fact it will help relaunch the tests when
> > one is failing,
Willy,
William,
On 3/8/22 16:14, Willy Tarreau wrote:
Due to this I think we should move the build of vtest after the build
of haproxy (and generally, anything that's not needed for the build
ought to be moved after). This will at least save whatever can be
saved on failed builds.
That on the
William
On 3/8/22 16:06, William Lallemand wrote:
Also, I'm wondering if we could also cache the build of HAProxy, you
could think that weird, but in fact it will help relaunch the tests when
one is failing, without rebuilding the whole thing.
Please don't. You always want to run a clean build
Hi William,
On Tue, Mar 08, 2022 at 04:06:45PM +0100, William Lallemand wrote:
> Hello,
>
> The attached patch implements a somehow ugly way to cache the VTest
> binary, basically it gets the commit ID by doing a curl of the
> master.patch on the github URL.
>
> It allows to save ~8s per matrix
Hello,
The attached patch implements a somehow ugly way to cache the VTest
binary, basically it gets the commit ID by doing a curl of the
master.patch on the github URL.
It allows to save ~8s per matrix row, which is around 160s in total. I
know there is a small window where the curl and the git
On Tue, Mar 08, 2022 at 02:51:26PM +, David CARLIER wrote:
> Hi to (re)close #1555. :-)
Thanks for the quick fix David. I've copied a piece of the error output
into the commit message as it's always helpful for those facing build
breakage.
Now merged, and if this time it's OK I'll backport i
Hi to (re)close #1555. :-)
cheers.
From afc36e0ee99504f4da82815256a374179872b148 Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Tue, 8 Mar 2022 14:49:29 +
Subject: [PATCH] BUILD/MEDIUM: freebsd build fix.
Supporting kFreebsd previously led to FreeBSD (< 14) build breakage.
---
include/ha
Hi guys,
On Tue, Mar 08, 2022 at 01:46:50PM +, Marno Krahmer wrote:
> Hey Tim,
>
> I added a reference to the GitHub issue to the second line of the commit
> message.
Too late, I took the one you posted on the issue and that Ciprian
confirmed. No big deal anyway.
Cheers,
Willy
Hey Tim,
I added a reference to the GitHub issue to the second line of the commit
message.
Cheers
Marno
Am 08.03.22, 14:42 schrieb "Tim Düsterhus" :
Marno,
On 3/8/22 14:38, Marno Krahmer wrote:
> Is it enough to send the patch to this mailing list?
>
Yes, and the patc
Marno,
On 3/8/22 14:38, Marno Krahmer wrote:
Is it enough to send the patch to this mailing list?
Yes, and the patch looks good to me. Just one thing: Please reference
the issue ID in the commit message like this:
This fixes GitHub issue #1461.
Adding Willy to Cc.
Best regards
Tim Düster
Hey,
I added a patch to the GitHub issue that explicitly sets a color for this case.
I just took the same color as for backend servers that don't have a health
check assigned.
This definetely improves the situation and makes information readable again.
It would be nice to have the patch applied
Ciprian,
On 3/8/22 12:57, Ciprian Craciun wrote:
I've forgotten the screenshot... :)
see: https://github.com/haproxy/haproxy/issues/1461
Best regards
Tim Düsterhus
I've forgotten the screenshot... :)
> Thierry provided a "dark mode" CSS for the stats page, because apparently
> switching from dark pages to a bright one is painful, and some browsers
> on some OSes support this by default (on Linux I had to install a specific
> Firefox extension for this). Thierry has no opinion on the chosen colo
I've just tried to install HAProxy 2.5.4, as provided by the OpenSUSE
`servers:http` package; I'm upgrading from HAProxy 2.4.1.
Running `haproxy -c -f /etc/haproxy/haproxy.cfg` fails with exit code
1, but without any other message. (It previously complained about
`nbproc 1`, which I've removed.)
30 matches
Mail list logo
