I am trying to add some extra configuration options to an existing core plan (i.e. rabbitmq). This workflow mostly involves editing the hooks folder and reloading the service, without ever touching the plan.sh file. E.g.:
vim hooks/run
build
hab svc unload my-source/rabbitmq
hab svc load my-source/rabbitmq
Am I right in assuming that I need to rebuild the plan in order for changes in the hook to be picked up by the supervisor? if so, is there any way around this you can recommend? For some plans, the build step might take a few minutes, so it would be nice if one could execute only the packaging step instead of the entire script.
The build step does more for hooks than just notify the supervisor of changes, it also handles interpolating the handlebars expressions.
I don’t think we have an officially supported way to just run the hook processing step, but if you really want to do fast iteration, you can probably edit the processed output (in /hab/svc/rabbitmq/hooks) directly. This isn’t a supported workflow, though, so make sure that once you get things behaving the way you want, you make the equivalent changes to the hook sources and test with a proper build.
Also, if you’d like to file an issue about faster builds when only hooks have changed, that would be welcome.
Editing the processed output in /hab/svc/rabbitmq/hooks sounds like the correct course of action to me. The workflow would look like this:
Edit the hook in /hab/svc/rabbitmq/hooks
hab svc unload my-source/rabbitmq
hab svc load my-source/rabbitmq
This will allow you to iterate on the hook, make sure you copy any changes to your package source code once you get it working the way you want to and rebuild the plan
Please let us know if you run into any issues with this workflow (or any issues at all).
I will often iterate on editing /hab/pkgs/<origin>/<pkg>/<version>/<release>/hooks and then runing hab svc unload followed by hab svc load. If I know that I need to make lots of exploratory changes to the hooks this saves a bunch of time building, moving the hart file and installing for each change. Also, I think it si better to iterate in /hab/pkgs than /hab/svc since my changes will include the templatized content and when I feel good about the hook, I simply copy the whole thing into my work repo. At the end I will do an actual build and test that build for good measure.
@baumanj@nellshamrell@mwrock thank you all for helping with this! It makes indeed sense that this workflow is not supported and perhaps undocumented, yet it’s a very useful tip to save time while developing complex plans. I will try both the approches suggested and let you know if I encounter further problems!
