On Wed, Dec 6, 2017 at 7:57 PM, Alfredo Deza <adeza@xxxxxxxxxx> wrote: > On Wed, Dec 6, 2017 at 2:18 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: >> hey Alfredo and other Cephers, >> >> i am trying to disable master,mimic-* and probably PRs targeting these >> branches building on trusty. otherwise the binaries built on trusty >> with the new GCC ABI will not be able to run on trusty installation >> without the new libstdc++ installed due to missing libstdc++ ABI >> symbols. for more context, please see the recent discussion thread in >> this mailing list, search "C++11, std::list_size(), and trusty" for >> it. >> >> for example, if a branch is pushed to ceph/ceph-ci, jenkins will build >> it, and upload the built packages to chacra. even if all trusty >> testnodes are reimaged with xenial. we still want to make sure that >> people using trusty won't run into troubles if they want to use the >> packages built using our build infrastructure. so, we need to use the >> old toolchain to build jewel and luminous. >> >> so the status quo is: >> >> - jewel, luminous, mimic-dev* and master built on trusty are using GCC-7 >> >> and the goal is to >> >> 1. build jewel and luminous on trusty with the old GCC shipped with the distro https://github.com/ceph/ceph-build/pull/928 should address this one. >> 2. do not build master, mimic-dev* branches on trusty >> >> the same applies to the branches targeting respective releases pushed >> to ceph/ceph-ci . >> >> but after digging around in ceph/ceph-build, i realized that probably we need: >> >> 1. a naming convention for branches targeting jewel/luminous, like >> wip-fix-a-bug-luminous. > > A naming convention sounds OK to me. I would prefer to have luminous > at the beginning. If using 'wip-' is a must, then something like: > > wip-luminous-fix-a-bug > > Otherwise: > > luminous-fix-a-bug > > On ceph-volume pull requests we've followed the latter. > >> >> this helps with solving goal #1: so we can skip the steps preparing >> the GCC-7 when setup pbuilder. >> >> this also helps with solving gobal #2: we have no way to tell if a wip >> branch is targeting which release without actually cloning it and >> looking at the source files or using "git describe". but typically, >> jenkins will not have access to the source files or the .git directory >> of a PR or a ceph-ci repo before the "ceph-*-setup" job. and i'd like >> to prevent jenkins from scheduling a job at the very beginning: so the >> only metadata at that phase is the "$GIT_BRANCH". that's why i suggest >> use a naming convention for these branches. so jenkins is able to >> identify them. > > This is all on point on how we detect these, and what is available at that point > >> >> 2. we need to have a "combination-filter"[1] referencing the >> $GIT_BRANCH, like "!(["master", "mimic-dev1"].contains(branch) && >> DIST=="trusty)". where "branch" is an axis, calculated using >> $GIT_BRANCH. >> >> i am not sure if #2 is a feasible approach. because i *think* the >> supported axises are setup when the jenkins-job-builder populate the >> yaml configuration files to jenkins. if that's the case, we cannot >> parameterize the "combination-filter" at run-time. > > We do have a job that 'triggers' these other ones, configured with the > 'trigger-builds' section on JenkinsJobBuilder. We don't use > 'factories' there but that might be able to help here: > > https://docs.openstack.org/infra/jenkins-job-builder/builders.html#builders.trigger-builds > thank you, Alfredo! i will give it a try later on. >> >> >> any idea or comment would be appreciated! >> >> >> cheers, >> >> --- >> [1] https://docs.openstack.org/infra/jenkins-job-builder/project_matrix.html >> >> >> -- >> Regards >> Kefu Chai -- Regards Kefu Chai -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
