On 2014-28-08 9:13, Dominic Cleal wrote:
On 26/08/14 18:23, Eric Sorenson wrote:
After the Puppet 3.5.0 release problems, we had a retrospective and tried to
figure out some process improvements which would have surfaced the problems
earlier. Despite a lengthy 4-week release candidate cycle, that release still
had a fatal flaw that nobody had caught until it went into final release. As we
talked it over, our thoughts turned to continuous delivery. Puppet (along with
most of the other open-source projects) already produces packaged artifacts as
moves through our Jenkins pipeline, so it seemed like a natural step to make
those packages publicly available.
In lieu of release candidates, we are moving toward a more automated system
which will have the latest green builds (passed spec and Beaker acceptance
tests) cut off the 'master' branch for most of our projects.
Would it be possible to build packages for other branches (like
puppet-4, or facter-2 when it was in development) in the future? I'm
especially interested in tracking incompatible Puppet 4 changes.
We really hope that the puppet4 and facter2 branches were a special
circumstance. It is not our intention to have long running feature
branches. As soon as 3.7.0 is released, the puppet4 branch will be
merged to master, and the puppet4 branch will be retired.
Since 3.7.0 is about to be released very soon there will not be any
puppet4 builds in nightly (until it is on master).
(http://copr-fe.cloud.fedoraproject.org/coprs/domcleal/puppet4-nightly/
are my builds of puppet-4.)
What this means is that as we near feature complete on a release, like the
coming Puppet 3.7.0 release, users like yourself can begin trying out the
packages to ensure that the new features haven't broken anything you depend on,
and that the new features work the way you expect/want them to.
The repos are live now and you can try them out by following these directions:
https://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#using-the-nightly-repos
Hopefully this will help get faster turnaround AND better coverage. Please let
us know if you find it useful!
This is great, many thanks.
I had been building RPMs on copr (dead easy with Puppet's packaging
helpers) and running Foreman's installer & smoke tests with them, which
helped us spot incompatible changes and regressions quickly. I'd
encourage everybody to do something similar if they have a similar test
suite, it's been very valuable.
+1
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/ltnkn2%24360%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
