This commit introduces a new class (ThirdPartyHook), which centralizes
the handling of third-party hooks (scripts that project set up via
the configuration file). Most of the code is simply a move of the code
from maybe_call_thirdparty_hook, with a couple of enhancements:
- Ability to specify the directory from which to call the hook;
- Handling of the situation when calling the hook itself fails.
We can already see the benefits of this in function style_check_files,
where the code now necessary to call the style_checker is both clearer
and more compact.
In the future, the intent is to push this class one step further to
allow users to specify hooks to be fetched from the repository, rather
than requiring that the hooks be installed (usually by an admin) on
the machine hosting the repository. The current class' API should
allow us to implement this in a way that's transparent to all users.
Change-Id: Ie8bf8accbbfd75a91b914628fad27d780532dac4
TN: T209-005
This commit enhances the hooks to read the repository's configuration
from the most recent version. In particular, if an update is updating
the refs/meta/config reference, then read the configuration from that
update, instead of reading from the existing refs/meta/config reference.
For updates of all other references, the behavior remains unchanged.
A testcase (T227-003__meta_config_is_immediate) is added to verify
that refs/meta/config reference creation works as expected.
Following that change, various testcases also needed to be adapted
as follow:
- MC27-006__meta_config_branch_create: Creating the refs/meta/config
reference now works;
- QC13-022__checker_config_on_its_own: This testcase was pushing
a local branch called "meta-config" to refs/meta/config. This
update introduced a style-checker-config-file configuration. Since
the configuration is now taken into account right away, the update
is was rejected due to the file not existing.
The branch "meta-config" is renamed to "meta-config-missing",
and a new branch "meta-config" was created, containg the missing
file in addition to the configuration changes above.
We first try to push the "meta-config-missing" to verify
that this is rejected. We then try to push the (new) "meta-config"
branch, verifying that the presence of the config file allows
the push to be accepted.
- T209-001__update_hook_not_found: A similar situation to the above,
but with the update hook. The added comments in the testcase
should make the changes self-explanatory.
- T209-001__update_hook_reject: Modify the update-hook, which is
called during reference updates, to not reject the refs/meta/config
update the testcase is doing as part of the preliminary setup phase.
Change-Id: I0bd7bc0801ba08cd281a751759bba8c48ba0c454
TN: T227-003
This commit is only there to simplify the logic behind handing
the data passed when calling the post_receive.py script. In particular,
this script receives information:
- via the command-line, with the optional --submitter-email option;
- via stdin, with one line per reference being updated.
I don't know what I was thinking at the time, but somehow, the way
I chose to handle this was by appending to each entry from stdin
the arguments from the command-line, and then use an ArgumentParser
to pass each stdin entry. It works, but in practice, the it makes
the code more difficult to understand. In fact, when I read this code
again recently, I missed the tiny "+ sys.argv[1:]" and so it made me
(wrongly) believe that the command-line arguments were entirely ignored!
So, this commit simplifies this by clearly separating the phase
of parsing the command-line, and the phase of processing each
entry passed via stdin by git.
Change-Id: I2e01a99e7c1931a56e9b95f196a2f73f9be70a2e
TN: T223-004
This option allows users to specify a script to be run at update time,
for each reference being updated. This script can then be used to perform
additional checks on top of the standard checks already provided by
our git-hooks.
Change-Id: Iff527f1c9c0ba516ea5181c5f8c066c5175ef0ee
TN: T209-001
The primary motivation behind this patch is simplification of
the code, after having noticed that both the update and post-receive
hooks create the object. So we can make it an attribute computed
at instantiation time, and simplify many of the methods implemented
by this class.
The second motivation behind this patch is also a slight performance
improvement, measurable when the number of files changed by a push
is getting more important. This is the change in pre_commit_checks.py,
which now takes an extra argument providing the project/repo name,
instead of recomputing it (involving running git) for each and every
file being checked.
The performance gain is fairly modest, measured to be around 4ms per
file being checked, but worth taking, given the fact that it does not
complicate the code in pre_commit_checks.
This allows the main script to return without having to wait
for all emails to be sent, especially since there is a delay
of several seconds being introduced between each email being
sent.
For LC28-010.
The hooks now enqueue all emails in that queue, and post_receive_email
now triggers the flushing of that queue at the end of the script
execution. The emails are still sent within the same process, but
the goal is to daemonize the part that sends it.
Part of LC28-010.
... rather than have EmailInfo.__init__ do it but controlled via
a parameter. We only want to do it once at the start of the post-
receive phase. Doing it this way ensures that it happens exactly
as planned, in case we (slightly unintentionally) instantiate
this class more than once - and with print_warnings left as the
default, which is True.
This should never happen, as we want to (and do) catch those
situations during the "update" phase. The exception handler
was therefore dead code by construction.
This attribute is used to store the value of all references
before an update is applied.
This was computed on-demand by expand_new_commit_to_list, but we want
to make this a parameter of this function, in order to allow us to
call this function from any hook. In particular, in the post-receive
hook, all reference values have already been updated, so the only
way to get the value of a reference prior to the update is by reverse-
applying the ref updates passed by argument to the post-receive hook.
The ultimate goal of this patch is to re-use expand_new_commit_to_list
during the phase where we send emails for each new commit.
This finally merges the two parallel infrastructures defined in
post_receive.py and the update modules+sub-modules. This allows
us to treat each type of update within its own module, rather
than having a gigantic post_receive.py file. Also, every aspect
related to a given update is all handled within the same module.
There was a unit test for post_receive.py's AbstractRefChange,
which has now been replaced by the corresponding unit test for
class update.AbstractUpdate. This also required a minor upgrade
of the unit-test infrastructure.
The changes should all be internal. There should be no user-visible
changes.
This class computes various pieces of info needed when sending
emails, and aggregates that info into one object for easy use
across functions. Adjust the rest of the code accordingly.
