Tests: Verify that 'rvm1_delete' functionality is honoured #221
Conversation
There was a problem hiding this comment.
I suggested a change (see associated comment), but I also believe the PR as it is is a great improvement already.
I am familiar with ServerSpec (not yet with Molecule, I believe they will work together afaik), and indeed if the test suite grows it could be interesting to have that in place, good thought!
|
A comment on this by the way:
I would personally like to keep this feature in the role, because otherwise I'll have to SSH into my machines. I do agree though that it should be able to deal with a list of rubies, work idempotently, so that I can keep the list of old rubies in there for some times (particularly useful if I wake up a slightly old vagrant VM which isn't up-to-date ; the old "delete" list will automatically clean up what's been moved to delete). |
I kinda agree with Thibaut on this one. So, everything that helps people to manage rubies (including removing old rubies), is good to be added to this role I think. But... rvm wasn't meant to deal with gems installation, gems are handled by rubygems (which is installed by rvm). So, I think bundler (and any other gems) shouldn't be managed by this role as it would add too much complexity as we already faced with bundler. I don't know if I'm the only one to think that way? :-) |
|
@gildegoma good job on the PR, it seemed like this was missing from the tests. I don't have any experience with the test frameworks so I can't comment on that, sorry. I agree, I think |
|
About improving (or evolving from) |
There was a problem hiding this comment.
I'm in favor of this 👍
It further covers testing, while acknowledging that more could be covered once we switch to a more robust testing methodology.
That switch to another testing framework shouldn't hold-up the fact that this is certainly incrementally better than what we had before. I like it. 👍
|
@pkuczynski I am in favour of this too ; this is a quality improvement on an existing feature that I still use regularly, so definitely happy to see this. I feel safer to delete one by one with this, compared to #222. |
|
Perfect. Waiting for build to pass and merging in! :) |
This is a first move to try to "fully cover" the features offered by this role.
It is maybe time to consider if this project should continue to implement its specs via Ansible assertions, or adopt some new framework (such as Molecule, TestInfra, ServerSpec, ...).
Bonus Question: Do we really want to keep such feature? If yes, maybe this should deal with a list of rubies... The question is motivated by ongoing debates about Bundler setup being a duty, or not, of this role.