[gluster-packaging] glusterfs-4.1.2 released

Niels de Vos ndevos at redhat.com
Thu Jul 26 10:59:38 UTC 2018


On Thu, Jul 26, 2018 at 06:51:00AM -0400, Shyam Ranganathan wrote:
> On 07/26/2018 03:22 AM, Niels de Vos wrote:
> > On Wed, Jul 25, 2018 at 02:48:22PM -0400, Shyam Ranganathan wrote:
> >> On 07/24/2018 10:10 AM, Niels de Vos wrote:
> >>> On Tue, Jul 24, 2018 at 01:04:39PM +0000, jenkins at build.gluster.org wrote:
> >>>> SRC: https://build.gluster.org/job/release-new/63/artifact/glusterfs-4.1.2.tar.gz
> >>>> HASH: https://build.gluster.org/job/release-new/63/artifact/glusterfs-4.1.2.sha512sum
> >>>>
> >>>> This release is made off jenkins-release-63
> >>>
> >>> CentOS packages have been built and should become available for testing
> >>> shortly.
> >>
> >> Tested the install and basic functioning of client and server bits on
> >> FUSE, found things to be in working order.
> > 
> > Thanks! Packages have been marked for release and hopefully land on the
> > mirrors later today.
> > 
> > We could setup a Jenkins job in the CentOS CI to do automated testing
> > once RPMs are built. Scripts that can be executed on client and server,
> > or an ansible playbook would be the easiest to integrate. Is there
> > someone that would like to provide these?
> 
> Well I have been asking for (something like) this after posting my
> testing scheme around RPM sanity. It will save about 30 minutes of my
> time, each time we package, but more importantly help us around
> timezones to not delay this.
> 
> This is how I test [1], so before we automate, is this acceptable?

Any functional test is acceptible to me. If we run this in the CentOS
CI, there is not even a need for containers and we'll just get a number
of servers (cleanly installed) that can be accessed through ssh directly.

> I see this scheme as viable for minor releases, for major releases we
> need to perform upgrade testing, which is more elaborate (test the doc
> and new options etc.) and needs more time to automate. I state this, so
> that we understand we can automate minor update RPM testing as I see it,
> but not for major versions *yet*.

Agreed, the first step of automated testing would be to install and
check basic functionality. Updating between minor/major releases can be
done at a later time.

Volunteers that would like to take on this task can contact me to work
through the details.

Thanks,
Niels


> [1] Package testing: https://hackmd.io/-yC3Ol68SwaRWr8bzaL8pw#
> 
> > 
> > Niels
> > 


More information about the packaging mailing list