You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if the PROCFILE environment variable is not set this buildpack will fail with an error. I would like to suggest that we don't fail right away but try and use the default Procfile and print a notice that we did. Only if no Procfile can be found in the root directory should we fail with an error. The PROCFILE can in this sense be regarded as an override, rather than a required definition. I believe this behavior should be a bit more user-friendly and about as easy to debug.
About my specifc use-case:
My code-base contains both a webapp and a storybook static site generator and each require their own build and run steps. Usually what I want is for the webapp to build/test/run as normal but for the storybook deploy I would like to override the build/run steps with as little changes as possible to the other deployment configuration. Adding a default PROCFILE value would allow me to leave it out everywhere but the storybook deploy.
If you feel that this seems like a good idea I'd be happy to contribute with a PR 🙂
The text was updated successfully, but these errors were encountered:
What should the contents of the Procfile be? Also what should the PROCFILE var be set to? Is it the path to the Procfile? so packages/web or packages/web/Procfile ?
@dnjstrom This seems better from a usability standpoint, but I must say that I do really like the explicitness in the way it works, today. I assume by "default Procfile" you mean the automatically discovered process types that the ruby, python, node.js buildpacks provide? I'm not entirely sure this will work, but if you want to experiment, I'm not against merging a PR.
Currently, if the PROCFILE environment variable is not set this buildpack will fail with an error. I would like to suggest that we don't fail right away but try and use the default Procfile and print a notice that we did. Only if no Procfile can be found in the root directory should we fail with an error. The PROCFILE can in this sense be regarded as an override, rather than a required definition. I believe this behavior should be a bit more user-friendly and about as easy to debug.
About my specifc use-case:
My code-base contains both a webapp and a storybook static site generator and each require their own build and run steps. Usually what I want is for the webapp to build/test/run as normal but for the storybook deploy I would like to override the build/run steps with as little changes as possible to the other deployment configuration. Adding a default PROCFILE value would allow me to leave it out everywhere but the storybook deploy.
If you feel that this seems like a good idea I'd be happy to contribute with a PR 🙂
The text was updated successfully, but these errors were encountered: