As part of determining which Update class it needs to instantiate
for the reference udpate being evaluated, the udpate factory
computes the following information:
- The kind of reference being updated (branch? notes? tag?)
- What operation on the branch is being performed (create? delete?
update?)
- The type of object the commit targeted by the reference
(commit? tag?)
In the context of enhancing the git-hooks to allow projects to provide
custom-checks on commits, the first and third items seem like these
could be useful information to pass to those hooks. In order to allow
this, without recomputing that information, this commit enhances
the AbstractUpdate class __init__ method to add those as additional
required paramaters, and then stores them as two new attributes.
As a bonus side-effect of this change, the new_rev_type attribute
is no longer necessary, which allows us to save one external call
to Git.
In the meantime, having these new attributes means that we can use
those to cross-check, within each AbstractUpdate child class'
self_sanity_check method, that the ref_kind and object_type values
correspond to each class' expectation (in other words, we cross-check
that the factory instantiated the correct class).
One other side-effect of that change is that we are no longer calling
the get_object_type function with a null SHA1 anymore. We could
modify the function's implementation to only accept non-null SHA1
revisions, but this would denature the function, in my opinion.
There is a genuine chance that perhaps, one day, we'll need that
again. So, instead, we cover that function by adding a new unit test
instead.
Change-Id: I8fd1ce180a6e17c0401b4dee07b9bc07d2abfdda
TN: T209-005
In other words, if you have a repository is configured with:
[hooks]
no-emails = refs/heads/master
The "hooks.no-emails" configuration should only apply to the master
branch, not any branch whose name happens to start with "master".
Incidentally, fixing this problem uncovered an error in the configuration
in the repository used in one of the testcases. This commit fixes that
error.
Change-Id: Ic3cdc56e4122fae65bbec792e12a002f2042b7e3
TN: T622-001
The idea is to introduce a new set of configuration options allowing
repositories to set alternate naming up for branches and tags.
And, in order to have the default to recognize all standard names
while at the same time give users an option to restrict the name
of the branches/tags that one can have in the standard naming,
we are introducing another option called...
use-standard-{branch,tag}-ref-namespace
... whose default is True.
For repositories that want to add alternate naming schemes without
restrictions in the standard branch/tag namespaces, they just add
the alternate branch/tags names via (with "xxx" being a regular
expression):
{branch,tag}-ref-namespace = xxx
For repositories that want to restrict the branch/tag naming within
the standard namespaces, they start by dropping the standard
ref naming, and then add the ref-naming that they want to allow:
use-standard-{branch,tag}-ref-namespace = false
{branch,tag}-ref-namespace = xxx
{branch,tag}-ref-namespace = yyy
To support this feature, the engine for determining the type of
update we are facing has been made more dynamic. Because things
are more flexible, it can be harder to understand what is happening
when users are faced with an error. In that context, a reasonable
amount of effort is spent trying to provide helpful error messages
for the more common error cases. More far-fetched scenarios are
covered by testing, but no effort is made to provide detailed
diagnostic (at least not yet).
A fair amount of testing has been added, covering a matrix of scenarios.
Some existing tests also had to be adapted as follow:
- check_update_utest: Adapt to the new (more precise) error message;
- post_receive_one_utest: The scenario we were using prior to
this change now triggers an exception, and so we no longer
reach the code we wanted to cover with that scenario. So modify
the repository data, and try to push a commit which is a tag
instead, using a reference name that indicates a branch.
Change-Id: I0b2404c4c4b0d240e9ad29458fb75ddd1cd7dc7d
TN: T209-003
Up until recently, it was thought that it was not possible for the hooks
to be called given a reference name with an old_rev and a new_rev
both null. As it happens, it actually is possible, and so this commit
adds better handling of this situation (instead of failing on an
assertion that they aren't both null).
A couple of testcases already testing the deletion of branches and
tags have been expanded to try the same, but using a full reference
name, instead of just the branch or tag's name. There was no need
to add a test for git notes, because there is no "short" reference
name in this case. So the test verifying git notes deletion was already
using the full reference name...
A test has been added to verify the behavior in the case when a full
reference name is used, and that reference does not exist in the remote.
Change-Id: If6e657312611ecbb0a66d0a8ae3763379d97e96f
TN: T329-003
This commit rewrites some code that was building a poor-man's version
of an enum type by an enum.Enum subclass. No functional change.
Seen while working on T209-003 (allowing custom ref naming)
Change-Id: I5dbe9b69a421c980b98f52896b6048d53dc1f764
Maybe there will be a need to allow certain branches in refs/meta
to be deletable, but for now, that namespace has a very specialized
use and while we haven't had a situation were deleting a branch in
that namespace has been needed, we certainly don't want the "config"
branch to be ever deleted, since we rely on it to get the hooks'
configuration. So, keep the current situation, which is the easiest
to implement: disallow all branch deletions in that namespace.
This patch just makes that decision explicit.
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 patch introduces the same factory-like mechanism used in
the post_receive hook. The intent is to merge the code from
post_receive into this infrastructure.
