(MODULES-4097) Sync travis.yml #115
Conversation
| puppetlabs-tomcat: [linux] | ||
| puppetlabs-vcsrepo: [linux] | ||
| puppetlabs-vsphere: [linux] | ||
| puppetlabs-xinetd: [linux] |
There was a problem hiding this comment.
Can we pull this out of the travis section?
There was a problem hiding this comment.
I originally had it as a top-level hash key called supported_oss that I could anchor around the yaml file, but msync assumes that all top-level keys are files and can't find a file called moduleroot/supported_oss and fails, so I moved it into travis arbitrarily and reference it elsewhere...
It's not great (and honestly I don't like supported_oss anyway because managed_modules.yml duplicates this basically, but that can't hold other data) but can't find a better way yet.
There was a problem hiding this comment.
there is a :global key (see https://github.com/voxpupuli/modulesync#how-it-works) that can hold configuration available to all files.
There was a problem hiding this comment.
Ooo, I can do that. That's sweet.
There was a problem hiding this comment.
Global is exactly what I'm hoping for 👍
There was a problem hiding this comment.
Unfortunately there is a bug: voxpupuli/modulesync#96
There was a problem hiding this comment.
And merged, so I'll get that out.
| puppetlabs-sqlserver: [windows] | ||
| puppetlabs-wsus_client: [windows] | ||
| puppetlabs-inifile: [linux,windows] | ||
| puppetlabs-stdlib: [linux,windows] |
There was a problem hiding this comment.
So these are not mutually exclusive but additive. Yes yes... 💯
There was a problem hiding this comment.
That's the goal, though no idea if it works yet... it may try and add the win32 gems on linux and fail.
There was a problem hiding this comment.
It's all a matter of making the templates smart enough, I'm assuming.
There was a problem hiding this comment.
I would prefer the Gemfile to be smart enough to understand which platform it is running on, instead of hardcoding these here.
There was a problem hiding this comment.
Okay, but I think that should be new ticketed work that we do after we get the branches merged.
There was a problem hiding this comment.
Eventually we'll be there with the other changes that have been suggested by @bmjen - for now there is a difference in the gemfile that gets extracted with the additional gems when Windows. However it could be the same.
hunner
force-pushed
the
travis_sync
branch
2 times, most recently
from
22ed0ea to
40a6f3b
Compare
hunner
force-pushed
the
travis_sync
branch
2 times, most recently
from
e5bdf68 to
afbfefa
Compare
hunner
changed the title
| - rvm: 2.3.1 | ||
| env: PUPPET_GEM_VERSION="~> 4.0" | ||
| bundler_args: --without system_tests | ||
| - rvm: 2.1.5 |
There was a problem hiding this comment.
The oldest ruby version we support in PE is 2.1.7 in PE 2015.2.3 (puppet 4.2.3). After March 31, 2017 the oldest supported ruby will be 2.1.9 running puppet 4.5.2 in PE 2016.2.1.
After April 30, 2017 we down to supporting the PE 2016.4 LTS containing ruby 2.1.9, and puppet 4.7.0.
Maybe we should start explicitly specifying those version combinations in the cells here, to cover (and maintain) the right combinations. And have one for the latest version to avoid scrambling updates when we release new versions.
There was a problem hiding this comment.
@ferventcoder What do you say about this? I took the ruby versions from the windows branch as they are more specifically chosen I believe.
There was a problem hiding this comment.
We want to be as close to what is in the AIO. So in this case, whatever the latest 4.x version is using we want to use. With other platforms it matters less but with Windows, it is paramount that the versions match exactly.
There was a problem hiding this comment.
I think we are maybe on 2.1.8 now?
hunner
force-pushed
the
travis_sync
branch
4 times, most recently
from
28974fb to
ab47af4
Compare
See also #116