Closed little9 closed 6 years ago
I think we initially had this in epigaea or laevigata as well. It might be worth taking a look at how their gem files and rake tasks are structured.
This should be prevented by this line in a project's Rakefile: https://github.com/curationexperts/mahonia/blob/master/Rakefile#L9, shouldn't it? I'm investigating.
None of the conditionals we have in place to check for production are actually working, in our local rake files, when running rake tasks from the command line. I checked Laevigata too, same problem there. Our Rakefile and ci and rubocop tasks all check for production to prevent solr_wrapper and other things from running, but the condition doesn't work. I tried a few variations on syntax, and an attempt with an ENV variable, but none worked.
I did get the import to run by commenting out the tasks in the files we don't want to run, then adding the rails_env to the rake cmd: rake MESH_FILE=/home/deploy/d2018.bin mesh:import RAILS_ENV=production
, then uncommenting our rake files. I'm going to close this ticket and open one about the conditionals in rake files not working properly.
Running the MeSH import rake task in prodution
MESH_FILE=/home/deploy/d2018.bin rake mesh:import
gives the following error:I think this is because
solr_wrapper
is a dev dependency. It looks like there was a similar issue with epigaea: https://github.com/curationexperts/epigaea/issues/147