Add option to install Stork during CI builds. about gatsby-plugin-stork HOT 3 OPEN

How about this plugin can configure for an optional env variable say - GATSBY_STORK_INSTALL_LOCATION (GATSBY_ prefix as per gatsby best practices). If that variable is set then where you are checking for if stork is installed in the plugin there can be an or check to also execute binary at this path and check if it's version or something to assert stork is installed.

Once that is done, when actually invoking stork for index creation - similarly we can use either stork cli command if it's natively installed or else use ./<ENV_VAR_LOCATION> to invoke stork.

How does that sound ? Would that be a trivial fix? For ease and reducing complexity with the plugin, We can simply ask the client to set the env variable to correct binary executable location (along with chmod +x). Since most will anyways only use this for CIs, this should be quite easy for them to set as well. @reese

from gatsby-plugin-stork.

I think the ENV variable sounds reasonable to me, especially for a quick fix for your use case. In the long term, I think it could also be useful to provide a default installation script during CI and then expose a config flag to optionally run it. There's an is-ci npm package that may be useful for that, and since I would assume that most CI uses Ubuntu, we could provide something similar to the build.sh in the docs and then call it with execSync from inside the plugin, which would mean that clients wouldn't even have to worry about installation. That's a longer-term solution though, we can always support those two separately.

from gatsby-plugin-stork.

@ashutoshsaboo I'll work on a more robust solution in the future, but I just published version 0.3.2 which has a GATSBY_STORK_EXECUTABLE_PATH env variable to override the stork executable location. Hopefully that at least unblocks you for now, but let me know if you run into any issues using that!

from gatsby-plugin-stork.