Re: continuous integrations

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 >

Re: continuous integrations pipeline frameworks

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

Re: continuous integrations

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. > >

Re: continuous integrations pipeline frameworks

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

Re: continuous integrations

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

Re: gnulib-tool.py speeds up continuous integrations

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

Re: gnulib-tool.py speeds up continuous integrations

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.

Re: syntax-check reject u_char u_short u_int u_long

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

Re: syntax-check reject u_char u_short u_int u_long

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

Re: syntax-check reject u_char u_short u_int u_long

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 \ >

syntax-check reject u_char u_short u_int 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;