сб, 21 нояб. 2020 г. в 22:46, Tim Düsterhus <[email protected]>:

> Ilya,
>
> Am 21.11.20 um 18:38 schrieb Илья Шипицин:
> > there's single job configuration without strict debug
> > https://github.com/haproxy/haproxy/blob/master/.travis.yml#L66
> >
> > I think there are couple of options available
> >
> > 1) add similar job definition to github actions
> >
> > 2) make DEBUG_STRICT=1 default and only option
>
> This is what I did. Anything crashing by using DEBUG_STRICT is a bug by
>

my english is not perfect, I know :)

look.

DEBUG_STRICT is enabled by default
https://github.com/haproxy/haproxy/blob/master/.travis.yml#L17

but is is suppressed for a single jon definition
https://github.com/haproxy/haproxy/blob/master/.travis.yml#L66

the idea behind it was "we'd better to test in strict mode, but who knows,
if there's something wrong without strict debug, we should also know"

my suggestion is to mimic previous behaviour ... or disable empty
DEBUG_STRICT at all maybe




> definition (compared to ASAN which might or might not be a bug). It's
> either a real bug or an incorrect condition in BUG_ON. Both must be
> fixed by a developer.
>
> >
> > also, we run ERR=1 for a while for various builds (linux, freebsd,
> cygwin).
> > I think we can consider that as default and only avaible option.
> > I'm not happy with various options that make test matrix really big
>
> Yes, ERR=1 is enabled for all builds in GitHub Actions. The only
> difference is whether warnings fail the build. It does not make sense to
> not fail a few of them when the cause is the same.
>
> Any build warnings should be treated as an error during development and
> then either fixed or silenced.
>
> Best regards
> Tim Düsterhus
>

Reply via email to