On 25 April 2017 at 07:43, Adel Boutros <[email protected]> wrote: > Hello, > > > We are currently compiling internally Qpid components using Jenkins on > Windows, Linux and Solaris. In order to ease the process, I was experimenting > with public CIs and have noticed you are using Travis (For Linux) and > Appveyor (For Windows). > > > So I was wondering if you could share your experience regarding the public CI: > > - How do you debug/fix a failing build? > > - Do you just check the logs outputed or do you access the machines > themselves? > > - Any drawbacks to this approach? > > - Any other info to share? > > > I was also wondering if you could provide me some tips on how I can do it for > the other OSes such as Solaris. We have internal VMs but would like to > protect them from security breaches and abuses. Should we use them or rely on > cloud infrastructure for example? > > > Regards, > > Adel
For the most part debugging CI build failures is done from looking at their log output and/or reproducing locally. There is some scope for more access though, e.g for Appveyor you can set it up to allow remote RDP connections and then do stuff on the node while the build is running, though I've never actually done it. For Travis, I have seen mentions of being able to rebuild jobs in 'debug mode' that lets you SSH in, but that may only be for private projects though, not much info out there. We also don't have as much access to configure the jobs on the Apache repo mirror as might normally be the case since the GitHub org they are part of is fairly locked down (and most folks aren't even in the org anyway). We can however fork the repos and enable Appveyor / Travis / etc directly on forks and do additional things that way if needed. We also use the ASF's own Jenkins CI build servers, https://builds.apache.org/. Its being consolidated just now to mainly Ubuntu instances with a few Windows instances to make things more maintainable, as although there used to be the odd OS X / FreeBSD / Solaris node offered by the core infra team they were simply never reliably available for use and were either old or not cost effective to maintain and so were chosen to be removed. That said, there is still the odd more exotic node in there, in some cases maintained by third parties for one or more projects use and then registered with the master node. I dont know of any public offerings around Solaris, though I don't know much of it generally so I wouldnt expect to either. Robbie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
