Suggestions:

1. Change :immediately to :delayed

template "/etc/default/go-server" do
  source   "go-server-default.erb"
  mode     "0644"
  owner    "root"
  group    "root"
  notifies :restart, "service[go-server]", :immediately
end

1. Add something along the lines of this:

Where plugins is a hash map:

"github-pr-status": "https://github.com/gocd-contrib/gocd-build-status-notifier/releases/download/1.1/github-pr-status-1.1.jar"

node['gocd']['server']['plugins'].each do |pluginName, pluginURI|
  remote_file "#{node['gocd']['server']['work_dir']}/plugins/external/#{pluginName}.jar" do
    source pluginURI
    owner 'go'
    group 'go'
    mode 0770
    retries 5
    notifies :restart, 'service[go-server]', :delayed
  end
end

I am receiving the following error when trying to build an AMI via chef-solo

https://gist.github.com/swade1987/febbc258b40c290297a744ee5229b3bf

However, when I do this via Vagrant it works fine.

What I did:
Included the gocd::agent recipe in my wrapper cookbook, with no overridden attributes:

include_recipe 'gocd::agent'

Then, ran a Windows 2012 R2 Kitchen suite to test agent install.

What I expected to happen:
Gocd cookbook downloads the correct gocd agent package and installs it.

What actually happened:
The remote_file[go-agent-latest-setup.exe] resource in gocd::agent_windows_install fails with a 404:

Recipe: gocd::agent_windows_install
  * remote_file[go-agent-latest-setup.exe] action create[2017-07-05T21:40:19+00:00] WARN:
    remote_file[go-agent-latest-setup.exe] cannot be downloaded from
    https://download.gocd.org/binaries/17.7.0-5147/win/go-agent-17.7.0-5147-setup.exe:
    404 "Not Found"

Cause:
The URL for the Windows agent is wrong. Going to the GoCD download page, you can see the correct address is https://download.gocd.org/binaries/17.7.0-5147/win/go-agent-17.7.0-5147-jre-64bit-setup.exe (notice the -jre-64bit in the file name, there is also a 32bit version).

Looking at the recipe, I see a source property, which uses the go_agent_package_url helper.

This helper in turn, uses the go_agent_remote_package_name helper. I believe this is the helper that needs to be modified to properly set the correct package names for Windows.

I would imagine this also happens with the GoCD server package, but have not tested it.

Possible Solution:
By means of Ohai, check if Windows is 32 or 64 bit, and create the Windows download URL as needed.

I have setup the following vagrant file - https://gist.github.com/swade1987/27203da681b6f6ebeffb

However when I browse to http://localhost:8153/ I get "no data received"

Per https://github.com/NOX73/chef-golang/blob/master/attributes/default.rb#L1, both this cookbook and the golang cookbook are using node['go']['version']. We're researching a workaround on our end.

More a comment than a issue.

When releasing new versions of the cookbook it would be nice if you could provide a mechanism to resolve older cookbook versions.

The release pushed to master today broke all our server provisioning because of the change for the apt-repo and version 13 is not available at the new loation

Seems that cookbook in Supermarket missing maintainer and email, but version is the same.
Please push stable build to supermarket! thx.

ERROR: cookbooks failed to write: HTTP error writing: 400 "Bad Request" cause: {"error":["Field 'metadata.maintainer_email' invalid"]}
ERROR: cookbooks failed to write: HTTP error writing: 400 "Bad Request" cause: {"error":["Field 'metadata.maintainer' invalid"]}

"maintainer":null,"maintainer_email":null,

It seems that a recent 301 redirect for the debian repository broke the server package installation. Ended up having to resolve with something like this to force the bintray.com URL. Anyone else experiencing this? If so, I can resolve and open a PR.

chef_gem 'chef-rewind'
require 'chef/rewind'

rewind 'apt_repository[thoughtworks]' do
  uri 'http://dl.bintray.com/gocd/gocd-deb/'
  key 'https://bintray.com/user/downloadSubjectPublicKey?username=gocd'
  only_if { node['platform_family'] == 'debian' }
end

with this error

Property resources of resource gocd_agent overwrites an existing method.

I am receiving a 403 error when the agent is attempting to download.

Hi,

When I use the LWRP the creation of local Go agents, the environments parameter doesn't seem to do anything.

By local, I mean on the same machine as the Go CD Server.

Here's an example of my LWRP implementation:

for i in 0..(node['wrapper_gocd']['agents'] -1)
  name = "go-agent-#{i}"
  gocd_agent name do
    go_server_host 'localhost'
    go_server_port 8153
    daemon true
    vnc    true
    autoregister_key
    autoregister_hostname name
    environments "Alpha"
  end
end

I've tried a few different inputs besides a string, such as an array, or referencing an attribute like #{node['wrapper_gocd']['go_env']}.

I haven't tried with remote agents, but I don't see any issues raised for that, so could this be an issue exclusive to remote agent creation or am I missing something (most likely)?

Thanks,
Raid

The search for recipe go server is not correct syntax to search the recipes on the chef server.

I could not create a pull request so please see line 24 and replace the recipe search with

 run_list:recipe\[go\:\:server\]

In the recipe agent_windows, the following 'opts' is specified in the following way:

opts = ""
opts << "/SERVERIP=#{server_ip}" if node['go']['agent']['server_host']
opts << "/D=#{install_path}" if node['go']['agent']['install_path']

The problem is, if both the ['go']['agent']['server_host'] and ['go']['agent']['install_path'] are specified, the /D option gets mangled because there is no space between the two options.

Any plans to upload this cookbook to supermarket.chef.io?

Installing package repos is currently broken due to go.cd being down

Assumes Debian distro, fails on CentOS

Currently source of Go installation is hard-coded to official thoughtworks repository.

It could be possible to install from alternative repository (e.g. mirror) or from raw package files.

Since GoCD provides an API to manage some of its resources, it would make sense to have Chef resources that could manage these.

The version can be found at — https://update.go.cd/channels/supported/latest.json

We can add additional keys in the JSON payload if needed, but for now, there's enough in there to know the latest version.

I am encountering some issues today with or chef provisioning running, when apt-get install is run it is failing with the following error. I have tried various versions and it is always the same.

Google doesn't really tell me much either, have ruled out our local proxy and apt mirror.

Anybody else seen this? Maybe it is aptitude is having one of its tantrums and I should try again tomorrow?

Failed to fetch http://dl.bintray.com/gocd/gocd-deb/go-agent-14.3.0-1186.deb  Got a single header line over 360 chars
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

https://supermarket.chef.io/cookbooks/gocd#quality

Update the cookbook to work with foodcritic 13.

Installing golang Go-agent from Debian package provides /etc/init.d/gocd-golang-agent file. Gocd cookbook also provides init.d file for golang go-agent. When using Gocd cookbook and 2 golang Go-agents, there are such files available after provisioning:

• /etc/init.d/gocd-golang-agent
• /etc/init.d/go-agent
• /etc/init.d/go-agent-1

and /etc/init.d/gocd-golang-agent is redundant.

This issue is well resolved for java Go-agents: Go-agent Debian package provides /etc/init.d/go-agent file and then Gocd cookbook does this: https://github.com/gocd-contrib/go-cookbook/blob/bf4cfe2e1a5d870af0e6f26c11b249fbc8fd89c3/resources/agent.rb#L68 . I suggest the same way for golang Go-agents.

I've submitted a pull request to add windows server install of go server.

1. Definitely add LWRP code for installing windows agents.
2. There might be an issue about server service not being installed/enabled in chef run. So it would be nice to test if service is running after reboot.

The attribute default['go']['agent']['server_search_query'] throws Net::HTTPServerException: 400 "Bad Request", it contains syntax errors.

The query should be corrected to "chef_environment:#{node.chef_environment} AND recipes:go\\:\\:server".

The service definition for the server has actions :enable and :nothing

This is notified by the package resource, which means that the server is started when the package is installed, but never again. It is configured to start on boot, but if the server goes down or is stopped manually, chef-client runs will never bring it up again.

Rather than hard-coding the Go version in the cookbook, have it query the apt/yum repo and install whatever is latest by default.

Allow users to specify a specific version via attribute.

Releases should be tagged so I can version pin in my Berksfile.

The apt repo appears to be signed but the recipe to set up the repo doesn't add a key. I can't seem to find where to retrieve the key for it to allow me to fix & PR. For yum it looks like you are disabling the gpgcheck...

As a result every time apt updates its package repos I get the expected error:

W: GPG error: http://dl.bintray.com Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9149B0A6173454C7

Running a go cookbook on windows server 2012R2, throws this exception below:

Recipe: gocd::server

      ================================================================================
      Error executing action `enable` on resource 'windows_service[Go Server]'
      ================================================================================

      SystemCallError
      ---------------
      The specified service does not exist as an installed service. - OpenService: The specified service does not exist as an installed service.

      Resource Declaration:
      ---------------------
      # In C:\Users\vagrant\AppData\Local\Temp\kitchen\cookbooks\gocd\recipes\server.rb

        8: service (platform?('windows') ? 'Go Server' : 'go-server') do
        9:   supports :status => true, :restart => true, :start => true, :stop => true
       10:   action [:enable, :start]
       11:   if node['gocd']['server']['wait_up']['retries'] != 0
       12:     notifies :get, 'http_request[verify_go-server_comes_up]', :immediately
       13:   end
       14: end

      Compiled Resource:
      ------------------
      # Declared in C:\Users\vagrant\AppData\Local\Temp\kitchen\cookbooks\gocd\recipes\server.rb:8:in `from_file'

      windows_service("Go Server") do
        action [:enable, :start]
        supports {:status=>true, :restart=>true, :start=>true, :stop=>true}
        retries 0
        retry_delay 2
        default_guard_interpreter :default
        service_name "Go Server"
        pattern "Go Server"
        startup_type :automatic
        declared_type :service
        cookbook_name :gocd
        recipe_name "server"
      end


  Running handlers:
  [2016-03-17T06:56:47-07:00] ERROR: Running exception handlers
  Running handlers complete
  [2016-03-17T06:56:47-07:00] ERROR: Exception handlers complete
  Chef Client failed. 0 resources updated in 24 seconds
  [2016-03-17T06:56:47-07:00] FATAL: Stacktrace dumped to C:/Users/vagrant/AppData/Local/Temp/kitchen/cache/chef-stacktrace.out
  [2016-03-17T06:56:47-07:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
  [2016-03-17T06:56:47-07:00] FATAL: SystemCallError: windows_service[Go Server] (gocd::server line :sunglasses: had an error: SystemCallError: The specified service does not exist as an installed service. - OpenService: The specified service does not exist as an installed service.

I would like to do a rubocop PR but I don't want to waste my time if it isn't going to get merged. I don't know the proper place for this request so I'm just creating an issue :P Let me know in the comments please.

Thx

P.S. - follow up PRs can then start to have tests (tailor, rubocop, foodcritic) and I think rubocop is a low barrier to entry for the tests. Thoughts?

Here is some conversation we had about creating go agent windows template.

To properly support windows templating we should be able to install agent without configuring it. That becomes an image template (AMI). Then booted VM can be configured by running chef to configure go server address, autoregister keys etc.

Essentially this comes down to being able to manage go agents windows registry values by cookbook.

I often find myself copy-pasting parts of this cookbook to fit specific end use cases.

I think many users would benefit if we provided gocd_autoregister resource. It would render the template to user-specified path.
It might be especially useful in customized installation scenarios when user is not interested in using our/official install packages. But he might still want some helper to get all registration properties in proper format to proper file.

go-agents setup with LWRP are created like here

The extra init.d scripts are created as symlinks /etc/init.d/go-agent-1 -> /etc/init.d/go-agent

The service is not enabled in /etc/rc2.d/ and trying to enable will fail:

sudo insserv /etc/init.d/go-agent-1
insserv: script go-agent-1: service go-agent already provided!
insserv: exiting now!

Reason is that go-agent is provided now by every go-agent-* instance.

# Provides: go-agent
# Required-Start: $network $remote_fs
# Required-Stop: $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Start the Go Agent
### END INIT INFO

When copied cp /etc/init.d/go-agent /etc/init.d/go-agent-1 and replaced Provides: go-agent with Provides: go-agent-1 then it works.

Probably cookbook should do copy and then replace service name instead of just creating links.

We should have go_agent chef LWRP so that user could define new agents like this:

go_agent "agent-1" do
  user 'go'
  group 'go'
  go_server_host 'go.example.com'
  go_server_port 8153
  daemon true
  vnc false
  environments %w(qa) # array or string
  resources 'ruby-2.1' # array or string
  autoregister_key 'bla'
  autoregister_hostname 'agent-1'
  action :start # probably passthrough to service actions
  workspace '/var/lib/go-agent-1'
  # memory limits?
end

It would still be possible to configure agents using cookbook attributes. gocd::agent recipe would look more or less like:

for i in 0..(node[:gocd][:agent][:count] -1)
  go_agent "agent-#{i}" do
     autoregister_key node['gocd']['agent']['autoregister']['key']
     # ...
  end
end

Notes:

• It would need at least 2 implementations of provider - windows and linux. Probably one per platform_family
• go-agents have native support for multiple agents on same host

I can't upload this cookbook with berks upload to a new chef server.

The server responds with: {"error":["Field 'metadata.maintainer' invalid"]}

This is an issue currently affecting many community cookbooks at present.

Please add maintainer and maintainer_email entries to metadata.rb to resolve this issue.

I have marked a few points which could be improved 867088c
Issues I am planning to fix:

• test compatibility with chef 11 and 12
• attempt to make node['go']['version'] = 'stable' by default (#26). Is there an URL that would return what is stable currently?
• refactor and document the backup and restore functionality which apparently works, but has no tests or readme
• add more detailed integration tests (test auto-registration of agents in particular that they are added and enabled)
• add chefspec tests
• extend readme on how to use the cookbook on various platforms
• I'd also like to assume that chefdk is now the primary development toolset
• setup snap-ci to run stylechecks, chefspec and kitchen integration tests in docker (as @ketan already did). If this will not be possible in long-term then I will be running integration tests on openstack locally.

I think it would also be nice to have LWRP for go agents. I will describe in separate issue.
I'd also like to split recipes into just installing Go packages and actually managing services. Default would be still to do both.
Probably I will write more tests before I add or refactor anything so that I will see if I break anything.

I will not do this all at once, but in time I should cover all of it.

What is the recommended way to setup GoCD server and agents? It seems like the agent cookbook here sets up 16? agents by default, which seems like a fair amount for a typical server. Should agents and server run on the same box, or seperate boxes.

For context, we're setting this up on an Openstack cloud, with 4 CPU, 8-GB RAM VMs as standard. Would it be best to have 1 VM for the server and 2-4 VMs for the agents, or would it make sense to install them all on the same VM. And how many agents per CPU?

This cookbook appears to assume that there would be only one Go server. If more than one server is found in the search, then it uses the first one found. If I want to allocate a go cd cluster per team, this would be problematic.

Perhaps provide an attribute called node['gocd']['server'] and set to nil, consequently allowing users to set this value. If they don't, then have logic that falls back on existing search logic.