On Thu, Jan 14, 2016 at 7:33 AM, John D. Ament <[email protected]> wrote: > What about a batch job that runs periodically to regenerate it and upload > it somewhere (e.g. nexus)? Then have the builds pull down that information.
Kinda close. Here's how it works in gory detail. Here's a page describing deployment: https://github.com/apache/whimsy/blob/master/DEPLOYMENT.md If you follow the second link, you will find: https://github.com/apache/infrastructure-puppet/blob/deployment/modules/whimsy_server/manifests/init.pp#L58 This runs every 30 minutes. The lines I'm pointing to say: pull from github, and if changed, run Rake update. And if you go to the Rakefile, you will see the following code: https://github.com/apache/whimsy/blob/master/Rakefile#L24 What this says to do is to run 'bundle update' on each Gemfile. (Note: the passenger applications use a different version of Ruby, something I home to resolve over time). Running bundle update produces the Gemfile.lock. Note in the specific case of the Gemfile in the www directory, the Gemfile.lock produced contains your local path. Perhaps over time we should look into checking in Gemfile.lock files, and changing the Rake update logic to skip over Gemfiles for which an associated Gemfile.lock is present, and run bundle install instead, which would use the specific version of every dependency indicated in the lock file. One thing I'm very happy about the whimsy-test setup (which will be the new whimsy in a matter of weeks) is that everything about the running operation is online. For the applications themselves, pushing changes is all you need to do deployment. For changing the configuration of the machine itself, submit a pull request against the infrastructure-puppet repository. As an example, here are the cron jobs: https://github.com/apache/infrastructure-puppet/blob/deployment/data/nodes/whimsy-vm2.apache.org.yaml#L45 My personal goal is to make this a very "patches welcome" kind of place. - Sam Ruby > On Thu, Jan 14, 2016 at 6:56 AM sebb <[email protected]> wrote: > >> The bundler/setup require creates a Gemfile.lock file. >> >> AIUI: >> >> This records the current actual versions of the Gems available at the time. >> Once created, it is used in preference to re-evaluating the versions. >> >> I think this may cause a problem. >> >> If we don't include it in version control, then deployed copies will >> create the file once then not update it. >> >> If we do include it, we probably need to make sure it is >> deleted/recreated on a regular basis. >>
