Thanks for all your replay, guys. I have read the doc that linked by Evans. I'm clearer for BigTop-CI workflow now. But for the job detail in current CI system, it's still a mystery. What should I do to fetch them?
The reason I have this requirement is that I'm now working on ARM arch support for Apache bigdata projects. Originally, we think that adding a new ARM CI for each projects is a good way. But then we found that BigTop has already added ARM arch in its CI. So we think that perhaps we may have cooperation with BigTop. While after did some reserach for BigTop, I got some thought and questions, Please blame me if I'm wrong. 1. I'm not sure that if BigTop-CI only runs the test in its repo or not. For each apache project, it have the test code itself, will these tests be ran in BigTop-CI as well? If not ,doesn't it mean the test coverage is small? 2. BigTop only tests bigdata projects with their released version. (For example. hadoop for 2.8.5). Is this a little lag? Suppose hadoop 2.8.5 has some issue for ARM arch, although BigTop-CI can found it later, is it too late? In my thought, BigTop-CI should find related arch issue before the project is released. 3. I know that BIGTOP is not a CI project. So if we push forward every project to support ARM CI, will it against BIGTOP's principle? I'm not familar with BIGTOP, so that I may misunderstand it in any side. Hope BIGTOP core team can correct me. Thanks, wxy Olaf Flebbe <o...@oflebbe.de> 于2019年6月13日周四 上午9:58写道： > > Hi > > let me add the detail that the job definition is only visible to the > developers role at bigtop ci. If you like to look what actually really is > done at that level — there might be some unintended diffs to what we > documented — we have to discuss how we can enable access for you. > > regards, > Olaf > > > Am 12.06.2019 um 04:19 schrieb Konstantin Boudnik <c...@apache.org>: > > > > Evans beat to me it ;) > > > > +1. I believe one of the reasons we have dropped the idea is a > > semi-baked state of the plugin in question (at least at the time). Perhaps > > it > > is time to let it go. > > > > I still like the idea to have all the jobs to be version controlled, and in > > a > > sense we are getting there by making CI jobs more "stateless" in a sense. > > Say, > > the core functionality of a job sits in a script in git and gets invoked > > (with > > necessary parameters) by the job to perform what is needed. Not all of them > > are like that, but that's the direction I hope ;) > > > > Cheers, > > Cos > > > >> On Wed, Jun 12, 2019 at 04:52PM, Evans Ye wrote: > >> You're right. That's outdated. I'd like to remove them. > >> The original thought was to have CI settings committed as code, however > >> we're not getting there yet. > >> > >> If you'd like to know the CI setting, go to Bigtop CI guide[1] and you'll > >> find some more up-to-date info. > >> To cope with our environment, we still have some workaround in our > >> production CI jobs, which I think mine not be necessary for users who just > >> target one single OS and Arch. > >> > >> Let me know if you have any questions. > >> > >> - Evans > >> > >> [1] > >> https://cwiki.apache.org/confluence/display/BIGTOP/Bigtop+CI+Setup+Guide > >> > >> Xiyuan Wang <wangxiyuan1...@gmail.com> 於 2019年6月12日 週三 下午4:31寫道： > >> > >>> Hi team, > >>> I'm a new newbie to BigTop, after read some offical docs, I have a > >>> question about bigtop-ci, > >>> > >>> BigTop has a CI system: https://ci.bigtop.apache.org/ Then I tried to > >>> find the definition of the job that running on this Jenkins systemd. > >>> But I failed. > >>> I finde a Jenkins DSL plugin file at the location > >>> "bigtop/bigtop-ci/jenkins/jobsCreator.groovy". While after reading the > >>> code, it seems that the jobs which are defined in this file is not the > >>> same with the jobs runs on the website. > >>> > >>> Is the file `jobsCreator.groovy` out of date already? Or my > >>> understanding about BigTop-CI is totally wrong? > >>> > >>> Hope someone could help me or is there any link can give me more > >>> information? > >>> > >>> Thanks very much > >>>
