For me I do not think a jenkins job will stop others to try other solutions, like buildbot or travis CI or other CI tools.
We can both provide our solutions, at least a POC, and then start to argue which one is better. And maybe both ways are fine, or we can find a way to them all in one. For HBase, we use both jira and github, and you can upload your patch on jira and then a jenkins job will test your patch and post the result on jira. And you can also create a PR on github and another pipeline jenkins job will test your patch and post the result to GitHub. Thanks. Gregory Nutt <spudan...@gmail.com> 于2019年12月21日周六 下午12:54写道： > Same answer. We need to clearly define how the workflow should behave > first. Then we will have a set of requirements that we can use to make > trade-offs against the design options. > > With no requirements in hand, it is just people supporting their > favorite tools or implementations they are familiar with. This is no > way to develop systems. We need top-down requirements analysis, then > and only then. bottoms up implementation. > > We cannot abandon good engineering practices. I think that putting the > workflow requirements together from existing discussion (if you could > find it) would be a simple job of an hour or so, if you don't get > murdered in your sleep for doing so. > > Greg > > On 12/20/2019 10:46 PM, Brennan Ashton wrote: > > On Fri, Dec 20, 2019, 8:31 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > >> And I could help setting up the jenkins jobs on the asf infrastructure > >> against github PRs to test them automatically. The website is > >> https://builds.apache.org/ . Plan to work with Haitao together next > week > >> on > >> this. > >> > > Could we please have a discussion on this before jumping into using > > Jenkins. I think there are some compelling reasons to use something > like > > GitHub Actions, especially with the ability to build on Linux, Windows, > and > > Mac easily. Also we can easily register outside runners which I would > like > > to wire up for a real device testing lab (I acquired hardware for the > imxrt > > family to do this prior to the Apache move) > > > > --Brennan > > >
