Hi Simon,
> Right. I also had trouble with Savannah git mirrors in the past, but
> for the past year or so it has worked well.
Interesting...
> One of the few disadvantages with this approach that I've discovered is
> that you don't get tight coupling of ci/cd script and the rest of the
> repos
Bruno Haible writes:
> Simon Josefsson wrote:
>> I forgot to mention: the pattern to provide re-usable GitLab CI/CD
>> definitions that I'm inspired by is Debian's pipeline project:
>>
>> https://salsa.debian.org/salsa-ci-team/pipeline/
>>
>> It is easy to setup a new project to use their reusa
Bruno Haible writes:
>> I think the pattern of having the .gitlab-ci.yml outside of the core
>> Savannah project is a good one for those GNU projects who are not
>> embracing the GitLab platform. Then GitLab-related stuff stays on the
>> GitLab platform and doesn't invade the core project.
>
> Y
Simon Josefsson wrote:
> I forgot to mention: the pattern to provide re-usable GitLab CI/CD
> definitions that I'm inspired by is Debian's pipeline project:
>
> https://salsa.debian.org/salsa-ci-team/pipeline/
>
> It is easy to setup a new project to use their reusable pipeline -- just
> add the
Hi Simon,
> These are useful pipelines with basic build testing!
My main use of these CI pipelines are to
- find regressions caused by commits in the respective packages,
- find regressions caused by gnulib (despite upstream having gnulib
as a git submodule),
- create snapshot tarballs
I forgot to mention: the pattern to provide re-usable GitLab CI/CD
definitions that I'm inspired by is Debian's pipeline project:
https://salsa.debian.org/salsa-ci-team/pipeline/
It is easy to setup a new project to use their reusable pipeline -- just
add the CI/CD configuration file setting poin
Bruno Haible writes:
> gnulib-tool is used is many CI jobs. Just adding 'python3' to the
> prerequisites of such a job makes it run faster. Here are the execution
> times for a single run, before and after adding 'python3', for those
> CIs that I maintain or co-maintain. In minutes and seconds.
>
Thanks for +1 Bruno, I have pushed the commits below. More history or
insight on how to think about use of these types would be great. My
recollection was that these types were preferred for compatibility with
ancient C tools that didn't parse 'unsigned char' etc.
/Simon
From 2adbe3be9e278cfc662
On 5/6/24 5:38 AM, Bruno Haible wrote:
>> sc_unsigned_int:
>> @prohibit=u''_int \
>> halt='don'\''t use u''_int; instead use unsigned int' \
>> $(_sc_search_regexp)
> Sounds good to me. My only suggestion is to move the sc_unsigned_long
> rule after the sc_unsigned_int rul
Hi Simon,
> How about adding inetutils u_* syntax-checks to gnulib's maint.mk?
>
> sc_unsigned_char:
> @prohibit=u''_char \
> halt='don'\''t use u''_char; instead use unsigned char' \
> $(_sc_search_regexp)
>
> sc_unsigned_long:
> @prohibit=u''_long \
>
How about adding inetutils u_* syntax-checks to gnulib's maint.mk?
sc_unsigned_char:
@prohibit=u''_char \
halt='don'\''t use u''_char; instead use unsigned char' \
$(_sc_search_regexp)
sc_unsigned_long:
@prohibit=u''_long \
halt='don'\''t use u''_long; in
11 matches
Mail list logo
