On Wed, Aug 23, 2017 at 5:37 PM, Ivan Necas <[email protected]> wrote: > > On Wed, 23 Aug 2017 at 15:10, Eric D Helms <[email protected]> wrote: >> >> There are a few different points to reply to, hopefully I did not miss >> one. For the base topic, based on feedback and target for post 1.16, I think >> we end up with: >> >> * 2.2 - postgres >> * 2.3 - postgres >> * 2.4 - postgres >> * 2.2 - mysql >> * 2.2 - sqlite3 >
+1 that should provide enough coverage > > This selection works for me > >> >> Jenkinsfile in Repos >> >> I think there are valid points and reasons for why this could be a good >> idea. However, I lean more towards this meaning a later goal and not an >> initial target. This would provide a more Travis like experience. I think to >> achieve this we need enough stability in both our job definitions, but also >> in the expectations that our Jenkins would be providing for plugins and >> other projects. If we want to share common code to make writing of the jobs >> easier, we need to have that common code stabilized or else we end up having >> to update multiple repositories every time we make a change. Thus, I would >> put this on the back burner as a goal when we stabilize. The centralized >> infra repository allows easier job definitions, and code sharing and >> development. >> >> Docker >> >> I would love to get to this point compared to how RVM setups work. I think >> this should be a second pass update that we make across the board after we >> make the first set of jobs given that we already know the slaves are >> configured and work with the RVM and database setups. I think we need to do >> some up front gathering and testing of information for things like: >> >> a) what all do we need containers of? (versions of ruby, OSes, databases, >> puppet availability etc.) >> b) which set of slaves can run docker? and label them >> c) what configuration updates do we need to make to slaves to run docker >> on them >> >> I think this can be done in parallel to my efforts if someone would like >> to take it on. We can add it to the wiki page as an item. >> >> Hound Dropping >> >> This probably deserves it's own thread whether we drop Hound in favor of >> using Jenkins to do the linting. >> >> >> Eric >> >> On Wed, Aug 23, 2017 at 5:05 AM, Michael Moll <[email protected]> wrote: >>> >>> Hi, >>> >>> On Tue, Aug 22, 2017 at 07:44:42PM -0400, Eric D Helms wrote: >>> > I am beginning to look at updating some of our test infrastructure by >>> > re-writing Jenkins jobs into the pipeline plugin [1]. This is a new >>> > style, >>> > with a different way of both writing and thinking about how jobs are >>> > crafted. I've started this work by attempting to write jobs for both >>> > Foreman and Katello [2]. >>> >>> +1! >>> >>> > ruby: 2.1, 2.2, 2.3, 3.4 >>> > databases: mysql, postgresql, sqlite3 >>> > >>> > I would like to propose the following: >>> > >>> > 1) We drop sqlite3 entirely >>> >>> At least one Ruby version should get tested with sqlite3, as almost all >>> dev setups will be sqlite and that's making it easy to reproduce test >>> failures. >>> >>> > 3) We pick the most widely used Ruby version and test mysql with that >>> >>> Sounds OK. >>> >>> > 2.2 -- used in RPM production >>> >>> This will need to get updated for Rails 5 anyway. >>> >>> > 2.1, 2.3, 2.4 -- used by Debian production >>> >>> 2.1 is Debian/jessie, which will be dropped with Rails 5. 2.4 is not >>> used in any Debian or Ubuntu version and it's highly likely that >>> Debian/unstable (and thus the next Ubuntu LTS 18.04) will go from 2.3 to >>> 2.5 directly. >>> >>> At the end with Rails 5 only Ruby 2.3 and 2.4 would stay and 2.5 get >>> added in Q1/2018. Depending on the RPM situation 2.4 could get dropped >>> theroretically again in Q2/2018. >>> >>> Regards >>> -- >>> Michael Moll >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "foreman-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> -- >> Eric D. Helms >> Red Hat Engineering >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
