Cooking Windows (messily) #325

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@maxlinc
Contributor

maxlinc commented Jun 4, 2014

This PR contains a quick-and-dirty recipe for creating a standard worker on Windows. It meets most of the requirements of travis-ci/travis-ci#2379. See #324 for a test suite to verify these recipes... and to allow us to refactor towards a cleaner approach in the future.

The things that make this quick and dirty are:

  • The runtimes (Ruby, Node, etc) do not have version switchers (nodist, uru, etc). It meets the worker requirement that "every worker has at least one version", but we'll need version managers for the language-specific workers.
  • Most of the work is done in a single recipe that just call chocolatey with the default options (installing the latest available package). It'd be better if the work was moved to the appropriate cookbooks (e.g. ruby) that provide attributes and post-configuration.
  • I created a new role, worker_windows, rather than changing worker_standard to support windows. I think it may be good to merge them eventually, but we need to discuss how we're going to do platform-agnostic roles and cookbooks first.

Things that work well:

  • The recipes included in common.rb - git, mercurial, and subversion - provide a good example of how everything should probably work. They have cookbooks that support windows, so the definition of the role/build_environment becomes declarative: "The standard_worker should have git git" not "Install git with chocolatey for the standard worker (on windows)"
  • Berkshelf seems to be working well, but we need to discuss further how to move forward w/ Berkshelf and away from ci_environment/worker_environment folders.

Here's the current Berksfile, since it's not shown in the PR:

source "https://api.berkshelf.com"

cookbook 'travis_build_environment', path: 'ci_environment/travis_build_environment'
# Unpublished dependencies of travis_build_environment which api.berkshelf.com won't find
cookbook 'unarchivers', path: 'ci_environment/unarchivers'

So berks vendor or berks package actually fetch the majority of the cookbooks via http://community.opscode.com/, via api.berkshelf.com. The ci_environment folder is only being used for the two cookbooks I need that aren't published to the opscode community: travis_build_environment and unarchivers.

One option, if it's necessary to keep the split between ci_environment and worker_host at all, is to create a Berksfile.ci_environment and a Berksfile.worker_host, and then use:

berks vendor --berksfile=Berksfile.ci_environment ci_environment
berks vendor --berksfile=Berksfile.ci_environment ci_environment

@maxlinc maxlinc referenced this pull request Jun 4, 2014

Closed

Windows in the Kitchen #324

@sarahhodne sarahhodne added the windows label Aug 5, 2014

@meatballhat meatballhat self-assigned this Nov 25, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment