Pre/Post Hooks for all Commands #37
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This change makes it possible to assign pre/post scripts to all
rebar commands, and optionally to specify which module execution
they're tied to. This allows users fine grained control over
when scripts and/or shell commands should be executed, where such
extensions are absolutely needed. No changes to existing modules
are required, although for a command to run with an enhanced
execution environment (e.g., the port compiler providing the all
important DRV_LDFLAGS environment variables and the like) then
the module should export a function setup_env/1, which the
pre/post hooks will take advantage of.
An example of the setup_env/1 function has been implemented in
the rebar_port_compiler module, refactoring the environment
setup to avoid any duplication. The rebar.config elements are
processed as follows:
An {atom(), string()} tuple is processed once before or after
the current command, if the atom is prefixed with pre_ (or
post_) and suffixed with the name of the current command. In
this case, the second element (string) is treated as the shell
command.
An {atom(), [{atom(), string()}]} tuple is processed somewhat
differently. The first element is matched as before, but the
second element (proplist) is searched for each (plugin) module
that is executed. The "rebar_" prefix is stripped form the
module name and matched against the first element. Where there
is a match, the second element (string) is processed as the
shell command.
Several examples of this configuration have been added to the
rebar.config.sample file.
This patch processes each hook once before and once after the command.
The hooks are configured as a list of {Command::atom(), Hook::string()}
tuples, which are in turn configured under the keys pre_hooks and
post_hooks. The post hooks only run if the command succeeds.
This patch processes each hook once before and once after the command.
The hooks are configured as a list of {Command::atom(), Hook::string()}
tuples, which are in turn configured under the keys pre_hooks and
post_hooks. The post hooks only run if the command succeeds.
|
Thanks, merged. |
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hi guys,
I've reworked my previous pull request (from nebularis/rebar) and removed the erroneous commit (which I'll submit separately) as well as the code comments that shouldn't have been there.
This change makes it possible to assign pre/post scripts to all rebar commands, and optionally to specify which module execution they're tied to. This allows users fine grained control over when scripts and/or shell commands should be executed, where such extensions are absolutely needed. No changes to existing modules are required, although for a command to run with an enhanced execution environment (e.g., the port compiler providing the all important
DRV_LDFLAGSenvironment variables and the like) then the module should export a functionsetup_env/1, which the pre/post hooks will take advantage of.An example of the
setup_env/1function has been implemented in therebar_port_compilermodule, refactoring the environment setup to avoid any duplication. The rebar.config elements are processed as follows:An
{atom(), string()}tuple is processed once before or after the current command, if the atom is prefixed withpre_orpost_and suffixed with the name of the current command. In this case, the second element (string) is treated as the shell command.An
{atom(), [{atom(), string()}]}tuple is processed somewhat differently. The first element is matched as before, but the second element (proplist) is searched for each (plugin) module that is executed. The rebar_ prefix is stripped form the module name and matched against the first element. Where there is a match, the second element (string) is processed as the shell command.Several examples of this configuration have been added to the
rebar.config.samplefile.Cheers
Tim Watson