Closed OliverPereira closed 8 years ago
For reference this is the offending line
@olisun - I don't have a remote agent so I may not be able to assist directly, but it appears that the remote agent does not have the same Server Capabilities
as the master.
In the instructions for the master, it states:
Navigate to the Bamboo Administration | Server capabilities and click Detect server capabilities, this will detect existing RVM/ruby and their associated gemsets.
I'm guessing even though this is remote, you still need to do the same thing and trigger refresh of the server capabilities on each remote agent.
Please let me know if this does/doesn't fix it. As always, I'm open to pull requests to solve it.
The agent does have the same capabilities as the master.
I had to install rbenv under the tomcat home (/usr/share/tomcat) and I also had to create the same user the agent runs under and install rbenv over there also so that the paths match.
Unfortunately it still didn't work.
There is no such thing as " trigger refresh of the server capabilities on each remote agent."... The agents detect their own capabilities.
"The agents detect their own capabilities" may not be true given that the Capability
for the same label is null.
this.getCapabilityContext().getCapabilitySet().getCapability( rubyRuntimeLabel.toCapabilityLabel() );
Does the documentation state this somewhere as a behavior of a remote agent?
I have had a problem which feels familiar on a new setup (not remote) when I forgot to manually click the link detect capabilities
. Regardless, if you figure it out I'm open to a pull request.
From a quick search, it appears that agents do not detect their own capabilities..
I'm unfamiliar, but still looking at https://confluence.atlassian.com/display/BAMBOO/Agents+and+capabilities
I see:
https://confluence.atlassian.com/display/BAMBOO/Agents+and+capabilities
Capabilities can be defined specifically for an agent, or they can be shared between either all local agents or all remote agents. Note that the value of an agent-specific capability overrides the value of a shared capability of the same name (if one exists)
What does it say in the agent details?
https://confluence.atlassian.com/display/BAMBOO/Viewing+a+Bamboo+agent%27s+details
I have found where the problem is.
The plugin relies on a capability of type Ruby for it to work properly.
If Ruby is installed on the Master or the agents, then Ruby versions are detected automatically and the plugin works fine.
BUT auto detection is disabled for the master and all the agents and the capabilities are configured manually under the "shared capabilities" on the master.
But there is currently NO option to define a capability of type Ruby and defining a custom capability of type command is not detected by the plugin and the plugin fails to execute the task.
I have raised a support ticket with Atlassian but I am NOT sure when this will be fixed.
Please let me know how it works out. If you would write up a how-to or notes section for remote agents, it would be nice to add to the readme.
Hi
So does this plugin work with remote agents or not (sorry I'm not sure what the outcome of the prior conversation is)?
It does ONLY if automatic capabilities detection is enabled in Bamboo but automatic capabilities detection leads to other problems in Bamboo.
Okay, thanks for clarifying.
To my understanding the agent's have an open bug which means you cannot disable the automatic detection at the moment.
But yes - I can confirm as well that the plugin works perfectly with remote agents; all I had to do is only install RVM to agents (as we are using Chef - I used RVM cookbook with subrecipe system_install).
I am having a problem with HOME directory though; I'm running Chef's knife in a job and it's giving me this:
error 22-Jan-2015 13:43:45 /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/berkshelf-3.2.1/lib/berkshelf.rb:71:in `expand_path': non-absolute home (ArgumentError)
It was working fine when I was using a plain Rake in custom cmd + had defined HOME in run; but if I try do that here I will get errors of duplicate HOMEs set. Anyone has any ideas? I can create another issue about this - but it sounds a bit more like knife's problem.
all- I'm making some additions/updates including xvfb-run. While I have my dev environment going, if there I something I can do to accomodate remote agents, please let me know. Since I'm not running them, I don't quite discern what is needed (if anything).
We are running into the same problem with our Bamboo configuration (local agents detect capabilities and run tasks correctly; remote agents have the same ruby / gemset installations but fail during capability detection).
Our experience is the same as @olisun: there is no way to manually define a capability with the Type property set to "Ruby". The closest you can do is Type "Command", which then causes the check to fail on the remote agent.
Which leads me to this question: is it possible for plugins to add new options to the "Type" list? If so, this might fix the issue. Otherwise, it appears that the only way to get a capability with type "Ruby" to appear is via the "Detect server capabilities" feature on the master node. As others have pointed out, this only affects local agents.
@olisun: do you have a link to the Jira ticket you filed with Atlassian? For what it's worth, upvotes there might help getting this resolved...
is it possible for plugins to add new options to the "Type" list?
My uneducated guess is that it is probably possible. Pull requests are welcome.
Given my cursory searches, I found this doc regarding Server Capability Types in Bamboo. I'll give it a go to see if it'll be simple to define a custom type from the drop down, but I make no promises; I don't often write Java code.
The biggest allure of this doc is:
The Capability Type Module is used for registering custom capabilities for your Bamboo plugin.
You may want to use this module to:
- Provide a human readable name for your plugins capability
- Provide custom template for editing the capability
- Group multiple yet related capabilities. For example, Bamboo uses this module for its Mercurial support to define both the Mercurial and SSH executables used by Mercurial
The plugin doesn't currently have it defined in the XML, so hopefully that'll be a good enough starting point for it.
This will help you get setup: https://github.com/alienfast/bamboozled-ruby-plugin/wiki/Development
@Jimflip I ported your changes into my own fork and updated slightly to be compatible with master
in this repo: https://github.com/kirvin/bamboozled-ruby-plugin/tree/feature/remote-capability-detection. Other changes in my branch were made to bring in third-party repos and fix some eclipse build issues.
I can confirm that your changes work on our remote agents. Thanks for putting a solution together!
@kirvin @Jimflip @sam2themax
I'm looking at @Jimflip's changes and @sam2themax in #9. It seems like @Jimflip's changes are simplest and work with the ruby capability. Do you guys agree?
@sam2themax, does yours cover Jim's change and add 'command'?
Do we need to add 'command' manual capability if we use Jim's code?
BTW - I just got a remote agent running so I'm ready to integrate/test this.
@kirvin I don't think you need https://github.com/kirvin/bamboozled-ruby-plugin/commit/652a7ab680db906fb6885a49abf233a948a30719 if you are using Atlassian's SDK and atlas-mvn
for your commands.
@rosskevin I'm sure you're right--I don't have the Atlassian SDK installed on our Bamboo server, so it was more straightforward to get it working this way for testing out the patch.
@rosskevin I ran into some strange behavior with local agents in my changes -- yes, the other approach is simpler so I'll decline my PR.
Latest workaround jar is available via UPM, I'm still looking at capability types to make this easier.
Gentlemen - I've implemented capability types for both xvfb-run
and ruby
, you can now configure shared capability types for remote agents. As of yet, I don't have my remote agent working, but please take an opportunity to try out this code.
Executables
sectionIf this fails, uninstall plugin, and add again from the marketplace.
This worked fine for local builds, and it does stil have @Jimflip's workaround.
I had to open my ufw for 54663/tcp to get through, my remote agent is registered. Auto detection on the remote seems to have worked fine, I set up the remote agent the same as the primary regarding paths.
No feedback from the group, but auto detection on the remote agent is working well for me. Latest is available via UPM. Release notes here: https://marketplace.atlassian.com/plugins/com.alienfast.bamboozled.ruby.bamboozled-ruby-plugin/versions#b51
@rosskevin Thanks for the new build--we'll try out this update early next week.
@rosskevin Was out for a couple days at the end of last week, but we'll give it a try this week, too. Thanks for getting this out.
@rosskevin Hi sorry, just back from my holidays. The fork I did was just a quick hack, I didn't have the time to delve further. I'll give this fix a run in our system, and report back any issues.
Thanks.
Here are my notes on remote agents:
https://github.com/alienfast/bamboozled-ruby-plugin/wiki/Remote-Agents
Please feel free to add/edit
Looks good to me -- also, the plugin is working well with our remote agents now. Many thanks!
I have installed and setup rbenv capabilities for my agents and for the master with the same path.
When I run the build on the remote agent I get the following error but when I run the job on the local agent it works fine.