Re: How to make releases with BuildStream: Feedback Wanted

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Tue, 2017-11-21 at 10:37 -0600, Michael Catanzaro wrote:
> On Tue, Nov 21, 2017 at 2:20 AM, Tristan Van Berkom 
> > <tristan vanberkom codethink co uk> wrote:
> >   o nobody as far as I can tell *cares* about these static release    
> >  modulesets anyway, nobody is building from the exact tarball     
> > build metadata that we've produced to match an exact release version 
> > (or, is this true ?)
>
> I believe that is true. But:
>
> > So, maybe it's possible to find some middle ground where we continue 
> > to publish the collective NEWS and new release versions published by 
> > module maintainers, but only publish build metadata for a tested 
> > "snapshot" of the latest git commit shas at the moment of a release ?
>
> The value of testing tarballs is that it allows us to know if a 
> downstream build has a chance of succeeding, because downstreams use 
> tarballs. So I don't think it would be appropriate to stop testing 
> tarball releases, like we do now. Every time I build a GNOME release, I 
> find at least a couple maintainers who I need to nag to make new 
> tarball releases, because other modules have begun to depend on some 
> unreleased functionality, or because the latest release of their module 
> is broken. So testing a moduleset built with tarball releases is very 
> important IMO.

Thanks for the feedback Michael !

I think my own personal conclusions to this discussion here and on IRC,
is that I feel like in the future, any autobuilders and CI that we
might consider should consider both "git branch" and "release" builds.

Right now I'm pulling apart convert-to-tarballs.py, which (I think) is
largely based on it's config file and the whitelist therein in order to
get the latest tarball available for a given module, the update of
jhbuild moduleset XML files is thankfully quite orthogonal to the meat
of the process, so I'm hoping to get a version of that to work with a
buildstream project before the next dev release happens.

I didnt really find time to make a public writeup of that experience,
but basically and for the record; the last release was done by:

  o Running convert-to-tarballs.py in the regular way in order
    to generate tarball based modulesets

  o Running jhbuild2bst[0] on the already converted modulesets
    (detailed explanation below).

So, basically my goal now is to reverse that process, so that the next
dev release is made by using the already automatically converted
buildstream project, and run the new version of convert-to-tarballs.py
against *that*.

As far as I can see, the remainder of the release process which
publishes the tarballs and aggregated NEWS files, are all based on the
"versions" file which convert-to-tarballs.py produces, so at least
*technically* speaking after this script is updated we should be free
to drop jhbuild at any time.

If we want to consider dropping convert-to-tarballs.py and instead
having a more verbose buildstream project (with a "release mode" as
described in the previous mail), we can consider that later, I dont
personally like the verbosity, but I dont like the conversion thing
much either...

Cheers,
    -Tristan

PS: More detail on how precisely I rolled the last release

# Install the jhbuild fork locally
#
$ git clone https://gitlab.com/BuildStream/jhbuild2bst.git
$ cd jhbuild2bst
$ ./configure --prefix=~/.local
$ make install

# Clone the gnome-modulesets-base repository, which is basically
# our buildstream replacement of sysdeps
# 
$ git clone https://gitlab.com/BuildStream/gnome-modulesets-base.git

#
# Do the convert-to-tarballs.py stuff, resulting in generated
# tarball based modulesets
#

#
# Now run the conversion using the generated tarball based jhbuild
# modulesets instead of upstream git based ones
#
$ jhbuild -m file:///path/to/gnome-apps-3.27.2.modules \
          bst --directory ~/gnome-modulesets-base/ \
          meta-gnome-core meta-gnome-apps-tested

The above results in a modification of the checked out
`gnome-modulesets-base` repository.

At this time I just recursively remove the `.git/` directory and
rename it, and run a build:

#
# Rename and prepare
#
$ rm -rf gnome-modulesets-base/.git
$ mv gnome-modulesets-base gnome-3.27.2
$ cd gnome-3.27.2

#
# Launch the build
#
$ bst --log-file ../build.log \
      --on-error continue \
      --error-lines 80 \
      build meta-gnome-core meta-gnome-apps-tested

The above will keep an extra log of the whole build and increase the
amount of output from the end of failed builds which appears in the
master build log, also it will not give you an interactive prompt when
a build fails but just try to build everything it can.

Finally after examining the results and preparing a release email, I
just tarred up that same directory which ended up here:
   https://download.gnome.org/teams/releng/3.27.2/gnome-3.27.2.tgz