develooper Front page | perl.perl5.porters | Postings from November 2019

Re: smoke-me branches, github, travis - wanting it all...

Thread Previous | Thread Next
George Greer
November 10, 2019 07:10
Re: smoke-me branches, github, travis - wanting it all...
Message ID:
On Wed, 6 Nov 2019, Nicholas Clark wrote:

> As Jim correctly observed, this should be its own message:
> The "migration to github" was described as being about bugs from RT to
> Github, with the potential of effectively swapping "master" and "mirror"
> between and GitHub
> To my knowledge there's been nothing mentioned about how everything else is
> supposed to work. Historically we'd been using smoke-me branches to get
> automated testing. github "thinks" otherwise about how to describe something
> that would like testing, but the existing smokers don't know that.

Someone that is part of the Perl organization could set up repository web 
hooks to send events (like new branch) to a CI server (like Travis or 
Jenkins) and automatically kick off smokes on their machines that would be 
reported on the PRs are checks passing or failing. We run that setup with 
Jenkins at $WORK.

> Likewise, historically all the requests I made in the other message here
> went to the list. In the brave new future, er, present, what *is* the plan
> for what goes where? We're now onto our third bug tracker, third hosting of
> version control, and not-sure-what iteration of mail archives.

Carlos Guevara (it appears) and I have machines that smoke every 
"smoke-me" branch that appears, so no requesting necessary.

To get the reports, check the smoking reports mailing list or visit a page 

There's also but it inexplicably 
doesn't allow searching by branch.

I stopped Cc:'ing people directly on smoke reports a while back due to 
controversy over whether that was worthwhile.

> So how are things supposed to be done?
> specifically - exploiting both any existing smoke-me smokers, but also
> github and Travis (and anything else that is "free")
> and more generally - getting the most out of github, without getting
> railroaded by defaults and features that don't fit what we need

The one nice thing that GitHub integration could give is I could set up a 
Jenkins server that OAuths to GitHub and lets anyone in the Perl 
organization kick off immediate builds with arbitrary configurations 
they've selected, instead of only asynchronous builds using the profiles 
I've chosen to run smokers under.

George Greer

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About