search

wolfeidau / rake-bamboo-plugin

Plugin for bamboo which enables building of ruby projects using rake
Other
34 stars 16 forks source link

Feature request: omitting patch-level from RVM Ruby selection #64

Closed tedpennings closed 4 years ago

tedpennings commented 10 years ago

Hi, thanks for the work on this plugin. I work with @eddiewebb and use this plugin daily for our builds.

I'd really like to see a change in the way Rubies are selected, to only select major versions. For example, I'd like to have the equivalent of rvm use jruby or rvm use 2.0.0. The current behavior is closer to rvm use jruby-1.7.10 or rvm use 2.0.0-p353. We don't really gain much by specifying which Ruby to use at that low of a level, so it would be nice to make patch-level selection optional.

We have a semi-large build farm and managing the minor patch levels of installed Rubies adds overhead we'd do well to eliminate. It would also give us more reliable builds. I think #62 might be caused by the plan specifying a Ruby that isn't installed; e.g., plan requires 2.0.0-p353 but only 2.0.0-p195 is installed, or requires jruby-1.7.10 but 1.7.5 is installed.

Gemsets should probably be supported at the major-release level, too, so you can specify jruby@rails4 or 2.0.0@rails4api, again, without patch level.

I'm open to collaborating on or sending a PR for this feature, but wanted to run it by you first.

Thanks!

wolfeidau commented 10 years ago

Yeah this seems like a great idea.

Probably the easiest way to do this would be to just add the fuzzy matching without changing the UI at all. Once this is done and proven, I think it mite be a good idea to add place holders for the normalised versions and see what others think.

I can certainly see how this would help as updates to various systems can provide slightly different patch releases, this is certainly the case with ubuntu.

And yeah depending on how familiar you are with Java I am happy to help with a PR.

tedpennings commented 10 years ago

Cool. Yeah, I'm very comfortable with Java, although Ruby has sucked out some of my desire to write Java ;)

The part I'm stuck on, from a design perspective, is how we go from the patch version 2.0.0-p353 to the RVM ruby 2.0.0, or, worse, jruby-1.7.10 to jruby. That's set in RVM. I can't really wrap my head around how best to embed that functionality - https://github.com/wayneeseguin/rvm/tree/master/config - specifically db and known_strings deal with that.

I'm thinking this challenge has two important components:

  1. Discovery. Every patch-level ruby is mapped to a major-level Ruby, so the RVM installation discovery maps those capabilities available for selection. This gets tricky because it's hard to know how to make that generalization up, without just hardcoding a bunch of regexes or cyclomatic complexity that covers the present Rubies in RVM.
  2. Usage. Every major Ruby gets mapped to some patch-level Ruby. This part is simpler. But how do we deal with conflicts when there are two patches of a major Ruby installed conflicts? Do we always choose the latest one?

I'd love to hear your thoughts on it. I will probably start hacking away at this, too. I might be overstating the problem.

eddiewebb commented 10 years ago

Awesome you're taking a look ted !

I think it is important to register the discovered rubies under multiple ids/labels fur the level of detail in a version. Thus would be similar to the jdk discovery in bamboo.

I.e. Register as: 2.0.0, 2.0, and 2.0.0-p395

This will let plans choose their level of preference in the task config. On Feb 5, 2014 12:10 PM, "Ted Pennings" notifications@github.com wrote:

Cool. Yeah, I'm very comfortable with Java, although Ruby has sucked out some of my desire to write Java ;)

The part I'm stuck on, from a design perspective, is how we go from the patch version 2.0.0-p353 to the RVM ruby 2.0.0, or, worse, jruby-1.7.10to jruby. That's set in RVM. I can't really wrap my head around how best to embed that functionality - https://github.com/wayneeseguin/rvm/tree/master/config - specifically dband known_strings deal with that.

I'm thinking this challenge has two important components:

  1. Discovery. Every patch-level ruby is mapped to a major-level Ruby, so the RVM installation discovery maps those capabilities available for selection. This gets tricky because it's hard to know how to make that generalization up, without just hardcoding a bunch of regexes or cyclomatic complexity that covers the present Rubies in RVM.
  2. Usage. Every major Ruby gets mapped to some patch-level Ruby. This part is simpler. But how do we deal with when there are two patches of a major Ruby installed conflicts? Do we always choose the latest one?

I'd love to hear your thoughts on it. I will probably start hacking away at this, too. I might be overstating the problem.

Reply to this email directly or view it on GitHubhttps://github.com/wolfeidau/rake-bamboo-plugin/issues/64#issuecomment-34212010 .

wolfeidau commented 10 years ago

Gday Ted

I had a look at those files you linked to in the RVM project and they actually look pretty easy to persist as meta data within the project.

So on load the project would load a Map of synonyms, with their matches stored in a list, then the UI bindings would merge that with the actual. I personally would just as suggested select 1.9.3 or 2.0.0 in 99% of cases..

Likewise when it comes time to locate the version it would use a routine to walk through the options based on information in the map and some simple file system checks.