Problem Statement:
Rails-packaging which currently houses our Rails SCL is being discontinued in favor of moving all the packages it holds over to foreman-packaging. We are doing this because the original intent was to have an SCL for just rails that other people could adopt and use. Over time we have seen no adoption by other people. This combined with increasing the complexity of our workflows by having the rails SCL in a separate repo has influenced us to go in this direction. This is so that we have a more inclusive way of working with the rails packaging, be more integrated into our workflows and be easier to work with and update.
The problems arising from this is what are the best ways that we should go about doing this without hurting nightly builds for a long period of time. So the goal is to make a clean transition from rails-packaging to foreman-packaging without blocking nightlies from passing, or blocking other builds.
Way to go about doing this:
First, instead of a using a SCL we keep all the rails tags under the foreman-nightly-rails-rhel7 tag we can also do this under the foreman-nightly-rhel7 tag. The only benefit to the foreman-nightly-rails-rhel7 tag being that we which will need to be created under the foreman-nightly-rhel7-build tag.We would drop the tfm-ror52 SCL in favor of having them all within the tfm SCL. This would reduce the overhead of managing two SCLs. we will also be obsoleting the old rails SCL packages when updating the new packages to use tfm-rubygem-*.
For this there are two methods to go about doing this:
First:
The first method would be to do two large commits. The first commit adding all the rails packages for 6.0 and then building them in order. As many of them require each other they’ll need to be built in a certain order. Then a second commit will be added changing all the packages that currently require the SCL versions of the rails packages and obsoletes the older SCL versions of the package. The advantage to this method is that we will get to the end point of having the new rails 6.0 packages the fastest, which also lets us build the rails 6 packages without having to depend on them first, after which we could .
Second:
The second method would involve instead starting with rebuilding the 5.2 rails packages while they are still depending on the 5.2 SCL packages. Once all of them have been built adjusting the packages in foreman-packaging that depend on them to rebuild against the newer versions of the packages. Once that’s accomplished we would make a commit with all the rails 6.0 packages and build those in the proper order. After which we could rebuild the other packages against the new rails 6.0 packages. This method might have a shorter amount of time where nightlies are broken, but will take a longer period of time before everything is done.
I think I am leaning in favor of option one, but I’m interested to hear if the community is in favor of either one, or has more points to make. I’m going to keep this open till Monday, December 16th, and then start out on the more well received plan.
