This commit updates the documentation of the hooks.no-emails
configuration option with some information which I had to fish
out of the implementation in order to confirm my understanding.
Change-Id: I1468265a715503735bb479fbe4e75ca63f3f5189
This commit enhances the commit emails we sent for Git Notes updates.
The goal is to include the names of the branches that contain the
annotated commit, similar to how we include the name of the branch
for regular commit emails, implemented in a way that this feature
covers all references, rather than just all branches (some projects
have branches under a non-standard namespace).
In summary, notes commit emails have their subject changed from...
[notes][repo] annotated commit subject
... to...
[notes][repo/branch1,branch2] annotated commit subject
Note that, if only one branch contains the annotated commit,
and that branch name is "master", then the subject remains
unchanged. This follows a practice we already have for regular
commit emails.
This commit also introduces a new config option called
max-ref-names-in-subject-prefix, which controls how many
such branch/reference names we include in the subject,
to avoid making that subject too long.
The full list of branches/references containing the annotated
commit is also included, unabridged, at the start of the "Diff:"
section.
Change-Id: I61ef0c497862f1243d3435a429120d63a27e4b3b
TN: S731-057
This commit add support for a new force-precommit-checks config
option, which allows projects to request that, on branches of
their choice, the precommit checks always be performed, even
when the commits were already present in the repository via
other references (pre-existing).
Change-Id: Ie24099ee7804d3eeec7d8d333a09811f48e5bf32
TN: V103-002
Now that the testsuite itself has been transitioned to Python 3.x,
we no longer have the means to make sure the hooks remain compatible
with Python 2.7. On a practical level, dropping support for Python 2.7
means we can start simplifying some of the code.
Change-Id: I07ec32840f462867c2879a71b64f89df93532760
TN: U530-006
Now that the hooks can be used with Python 3.x, time to enhance
the README to indicate which versions are supported.
TN: U530-006
Change-Id: I49c3fc05a484dfbecd6e10aea4d9e9221a75daa2
This config changes the default value of the hooks.no-emails config
to include the reference used by Gerrit to publish Git notes relative
to commits that just got submitted via Gerrit ("pushed" in Git parlance).
Change-Id: Idfc41b62cec889038ff76923154cc47728309e13
TN: U213-002
Projects with a git-hooks configuration using options which are declared
as a "tuple/list" cause the default of such options to be ignored.
This does not really make sense, because it forces users who want
to add to the default configuration to first repeat that default
configuration.
This commit changes the behavior to make sure that the git-hooks
don't drop the default when the user uses such a config option.
This is unfortunately a bit of a compatibility break with previous
revisions. In pratice, all but one config option ("hooks.ignore-refs")
have an empty default, so it's only a potential issue for that one
option. This "hooks.ignore-refs" option was created specifically
for Gerrit support and it is believed that the chances of a project
being negatively affected by this change are very small -- and if
this happens, we will provide a mechanism for allow the default
to be ignored. In the meantime, this commit updates the documentation
to make things clearer in that respect.
Change-Id: If5ce8ab7533da21bc3190f8b8fc154b17aa85a36
TN: U227-003
Note that, as part of the implementation, this commit introduces
a couple of calls to Git for each commit meant to retrieve the entire
list of files in a given commit. Luckily, one of these two calls
was already part of another check (filename collisions), and
the result of that call is cached in a CommitInfo object, so
the delta is only one extra Git call. Some performance measurements
seem to indicate that this is a fast-enough operation that users
should not notice the difference in performance, even for repositories
with a very large number of files [1]. If real-life usage proves
this assessment wrong, however, we'll revisit the documented behavior
so as to allow the use of a cheaper approach (e.g perform the check
on all modified files, rather than just the new ones).
[1]: Tested for instance on the GCC repository, which has more than
87,000 files in total; the first call took roughly 100ms, and
the next ones took about 60-70ms.
Change-Id: If0eea2c4990a945a3006cdd74d7a9aca2fc770d9
TN: T811-015
The current description makes it sound like this keyword disables
all precommit checks, but in fact, it only disables the style checks.
This commit clarifies this.
Change-Id: I8f8b8245b60d0e01d1ef48e5e416adeecddefe6a
TN: P426-035
This commit introduces a new config option hooks.commit-email-formatter
which allows projects to customize the emails being sent for new commits.
Change-Id: Ibd6b4991f15e204e0a076bb705fc8106f08ff8b4
TN: T209-006
This option allows projects to ask the git-hooks to perform custom
checks of any kind to validate every new commit being pushed.
This commit also contains a change in hooks/updates/emails.py which
enhances the email-sending debug tracing mechanism used by the testsuite,
adding support for a tracing mode where the traces are just one line
per email. Technically, this change is independent from the rest,
but it is merged with this commit nonetheless because these changes
would show up as uncovered by the testsuite without the testcases
we're adding here. That way, we maintain the principle that we always
have 100% testing coverage for any commit.
Change-Id: I0e446a95d05f5578f977af3eaa547144187eb86b
TN: T209-005
When a project's hooks.mailinglist configuration is the name of
a script, the call to that script now includes the name of the reference
being updated as the first (and so far only) command-line argument.
This allows these projects to have different mailing list addresses
depending on the name of the reference being updated.
Change-Id: Idc920357023c2b5ec7b3b4d755e298a0f0b83bf0
TN: T209-008
This is a followup on the previous commit, which introduced a feature
allowing projects to control which branches can be deleted.
This feature is added separately, as it is only a minor enhancement,
and this allows to keep the previous commit more focused.
Change-Id: I90d630e0a5b37d092db408379193e7a863201f8b
TN: T209-004
Note that tag deletion privileges are controlled via a different
and already existing option (hooks.allow-delete-tag). Also, notes
are not covered as notes deletion is currently not allowed at all.
Change-Id: I1ecfd83cf27861885f98c31bdc416f67d2dddb5e
TN: T209-004
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
The main purpose of that pre-receive hook is to ensure that any push
updating the refs/meta/config reference only updates that one reference.
A large comment was added to the code to explain why (in short, this is
a pre-requisite for being able to use the git-hooks config at the same
time the config changes are being pushed).
While at it, to be consistent with the other hooks, support for
a repository-specific pre-receive hook is added. One side-effect
of this is that we end up trying to query the hooks configuration,
which triggers a check for the existence of the refs/meta/config
branch. As a result, an extra copy of the same warning gets generated
when the reference doesn't exist. This is not super elegant, but
isn't a problem in practice, since this is part of handling a deprecated
feature that we'll try to remove support for hopefully soon. In the
meantime, this isn't blocking to adding support for the pre-receive
option.
Since this commit increased the number of times `refs/meta/config`
was spelled out (aka "hardcoded"), this commit introduces a new
constant to avoid duplicating that special reference name.
Change-Id: Ib4fc0a32f639fe693e4d43269baf8c0838fc9214
TN: T227-003
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
