Proof of concept for enabling inferno services start anywhere. #582
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proof of concept for discussion.
I believe that if we have command line tools that require an 'inferno environment' (that is, very specific services up and running for the command to work), then we must have a way to create the environment from any directory. Cloning "inferno core" and making users put files they want to analyze in that directory makes no sense to me.
This is just a quick and dirty proof of concept that it is not particularly hard for us to ship a docker-compose file in the gem. I can't say for certain there aren't edge cases to deal with, but in my environment this seems to work just fine (unless i messed something up and didn't actually use it how I thought I did :) )
I believe it works though... I used both
bin/inferno services start
from the inferno_core directory, as well as tried packaging it up as a gem, installing it, and then runninginferno services start
in other directories (then, going back to inferno_core, starting the web app, and running it to show that the services are fully up). I use rvm so the gems are installed to/Users/rscanlon/.rvm/gems/ruby-3.1.2
, but didn't try with other ruby version managers. I admit that there might be more complexities here, and I didn't really try everything, but I don't see what might be a problem here.I optimized here to keep the touch as small as possible, but also there are plenty of opportunities to clean this all up. Do we really need to maintain the old validator and the validator UI? Do we really need to persist redis? We should consider have the gem create a
~/.inferno/
subdirectory where we start storing stuff when not running within a Test Kit (I don't think redis matters, but the validator needs a cache to avoid rate limiting).Buttom line to me though: the evaluator will be fairly hostile to use once we get that into the CLI if we also have to say "now, clone inferno_core or some other test kit, go to that directory, copy your files to be analyzed there, etc etc". So we need this type of thing.