We noticed that Gerrit can create some references using the following
naming scheme:
refs/users/<last-2-digits-of-userid>/<userid>
When it does, this causes the hooks to fail with a message indicating
that it is unable to determine the type of reference it is, because
it doesn't recognize it.
This commit changes the hooks.ignore-refs default configuration
to ignore all references whose name start with "refs/users/".
We could be stricter in our matching, but I think this would be
slightly overkill. And meanwhile, we can see that this is not
the first time we notice that references in the "refs/users/"
namespace where created by Gerrit (e.g. we were already ignoring
references matching "refs/users/.*/edit-.*" before). So, being
being more relaxed here helps us avoid having to change the config
again in the future should Gerrit decide to expand on its use of
this namespace.
Change-Id: I3196cfc833ac94473d4b5fcdca773ded4ced24cf
TN: V218-013
A recent change enhanced the emails being sent for git notes
to also provide the list of branches (technically, the references)
which contain the annotated commit (S731-057). For instance:
| Subject: [notes][repo/branch] Annotated commit subject
^^^^^^^^^^^
And also this section in the "Diff:"
| For the record, the references containing the annotated
| commit above are:
|
| refs/heads/branch
However, there is a small hole in the implementation. I forgot
to take into account the "hooks.ignore-refs" config. As a result,
for repositories hosted on Gerrit, the emails mention references
which are internal to Gerrit.
| Subject: [notes][repo/master,(refs/changes/67/108467/1)] subject
^^^^^^^^^^^^^^^^^^^^^^^^^^
... and ... in the email:
| For the record, the references containing the annotated commit
| above are:
|
| refs/changes/67/108467/1
| refs/heads/master
This commit fixes this oversight.
Change-Id: I4e21d5c906e94c01b650615282258cc7b4fb81d9
TN: S731-057 (ticket introducing this feature)
TN: V105-012 (ticket opened to fix the oversight)
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 factorizes some code out of the AbstractUpdate class
into its own function, so that future code can use it.
This is preparation work for a later change where we want to enhance
commit emails sent for notes updates, where we want to include
in the information provided in the email the list of references
that contain the commit being annotated by each notes commit.
We want to provide that information in a way that's as readable
as possible, and this starts by spliting the reference name.
Hence this factorization.
One thing this refactorization made us realize is that Git currently
does not allow a push on references whose name does not have what
we call a namespace! This became apparent with this commit because
it changes slightly the way the code is written, exposing the fact
that this scenario wasn't covered by our testsuite. It was while
trying to add coverage for that scenario that I realized that Git
rejects such pushes. In the spirit of being flexible in what we accept,
the code is left as is, rather than replaced by an error or an assertion.
It is then validated via unit testing.
Change-Id: I3108d540ac82c7353fd5e73a12cd958f0877245a
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
This warning banner is triggered by the presence of an environment
variable to be set by the user prior to manually calling the
post_receive hook. This banner is then inserted at the beginning
of the email body in order to warn all readers of that email
that the email was not automatically sent at the time of push,
but rather at a later time.
TN: UC02-038
Change-Id: I42dece88dd0619df33adcc44d7adfc3ccd63a162
This commit changes the hooks to always use the quoted-printable
encoding when sending emails. This replaces the use of 7bit, 8bit
and base64 encodings. A comment is added explaining the reasons
for choosing this encoding.
For the record, the expected output in our testsuite has been
adjusted automatically using the following Python script...
| #! /usr/bin/env python3
|
| import argparse
|
| def fixup(filename):
| with open(filename) as f:
| contents = f.read()
|
| new_contents = contents.replace(
| """\
| remote: DEBUG: MIME-Version: 1.0
| remote: Content-Transfer-Encoding: 7bit
| remote: Content-Type: text/plain; charset="utf-8"
| """,
| """\
| remote: DEBUG: Content-Type: text/plain; charset="utf-8"
| remote: MIME-Version: 1.0
| remote: Content-Transfer-Encoding: quoted-printable
| """,
| )
|
| new_contents = new_contents.replace(
| "remote: Content-Transfer-Encoding: base64",
| "remote: Content-Transfer-Encoding: quoted-printable",
| )
|
| if new_contents == contents:
| return
|
| with open(filename, "w") as f:
| f.write(new_contents)
|
|
| parser = argparse.ArgumentParser()
| parser.add_argument("files_list", nargs="+")
| args = parser.parse_args()
|
| for filename in args.files_list:
| fixup(filename)
... calling it as follow:
$ cd testsuite/tests
$ /path/to/myscript.py */run_test.py
I think a perl oneliner was also possible, but I couldn't get it
to work (multiline issue, I think).
This still left one testcase that needed adjustement
(post-receive_from_email); I just manually adjusted it.
Change-Id: I8455d24f8fe0b9a732c68090a21091db060e03f2
TN: TB22-001
We have notice by auditing the call Gerrit's ref-updated
hook that Gerrit uses a number of other references for
internal purposes. Since those are internal, the git-hooks
should simply ignore them.
Change-Id: I46841da7926be7a69fc0f8e6c1def4834eb32a5b
TN: UC02-022
This is a change that comes from the transition to Python 3.x.
The only way it was detected by the current testsuite is that
the line of code located just after the call to warn appeared
as not being covered, which was odd, since the function "warn"
is supposed to always return. To investigate this further,
I simply added an invalid line of code right after the call
to "warn"...
except InvalidUpdate as E:
warn(*E)
invalid()
... and re-ran the testsuite: clean results (and invalid is
not covered).
Looking at the code more closely allowed me to realize that,
with Python 3.x, we need to pass *E.args, not *E. As a result,
we get an exception when calling warn as follow:
TypeError: __main__.warn() argument after * must be an iterable,
not InvalidUpdate
The reason we're not seeing this error in the testsuite is
because the issue is in a part of the file which only gets
executed when that file is used as a Python script, something
that the git-hooks don't do (the git-hooks imports the module
and calls the check_fast_forward function). Understanding this
then allowed us to track the testcase that tests the script,
and see that it was checking the script's status code, but
not its output. This commit enhances the testcase accordingly.
Change-Id: Icb92d82be6e108c6f05d84f0df5b787b97783082
TN: U530-006
Now that Python 3.x is required, this import is no longer useful.
Note that this commit deliberately excludes the imports done
in the testsuite, so as to allow these changes to be reviewed
independently of the changes to be made in the testsuite.
Change-Id: I28e1857df2cf0b2f9e7ddeab00b456d6ef513755
TN: U530-006
According to the function's documentation, we weren't planning
on keeping this function at all once the transition was complete,
but in thinking more about this, it seems prudent to keep it
nonetheless. The function's description has been rewritten to
explain why.
Change-Id: I60c83ab1846e969866ad67e3106eb6bfa4e77ea2
TN: U530-006
Now that Python 3.x is required, we no longer need to keep
some of the code in this function which was only run when
using Python 3.x.
Change-Id: Ib3a916d6b4536dc5741223a2801a55d914e187b1
TN: U530-006
We noticed that Gerrit's ref-updated hook was reporting some
errors when Gerrit makes updates to some of its internal references.
For instance:
| Traceback (most recent call last):
| File "./hooks/post_receive.py", line 126, in <module>
[...]
| errors.InvalidUpdate: ('Unable to determine the type of reference
| for: refs/changes/01/104201/meta', '',
[...]
This commit avoids this error by making sure that we properly
ignore all references that match the hooks.ignore-refs config
(note that, by default, hooks.ignore-refs includes matches for
those special Gerrit references).
A new testcase is added to verify that this is the case.
Note that the minor reformatting in maybe_update_hook comes from
black, which adds the extra coma only when the changes made in
this commit are made as well. This is why this reformatting change
is bundled with this commit.
Change-Id: Id94129ad1a9d84ccba6acafef3d8e98f62ec0239
TN: UA21-052
Other than pure convenience (and the fact that it allows callers
to not have to pass the ref_name each time it is called), there was
no real reason why this code needs to be defined as a method of
the AbstractUpdate class. This commit moves the code to a function
in the utils module, so as to allow it to be called from outside
the AbstractUpdate class hierachry, something we'll want to do
in an upcoming commit.
We still keep the search_config_option_list method for the convenience
it brings to the existing callers, but its implementation is simplified
to call the new function in utils instead.
Change-Id: Ie2e1f192da8522471c42910283a9c1f482daf6b0
TN: UA21-052
This makes sure that we no longer force the use of this version
of Python if it happens to be available on the machine where
the hooks are being run. Using gnatpython is no longer desirable
since it does not support Python 3.x.
Change-Id: I0505e455e3319b78502acbc79c359b79ca555b92
TN: U530-006
This is another preparation patch for the transition to python 3.x.
With Python 3.x, the output we get from the logger is going to be
a byte string, which we need to then decode into a string.
Change-Id: I2307b90f2e2cccaed8a93fa589f82fba0064c28b
TN: U530-006
This is another preparation patch for the transition to Python 3.x.
With Python 3.x, we need to make sure that the input used when
calling sendmail is converted to a byte string. We also then need
to make sure that the script's output is decoded into a string
when printing it.
Change-Id: I1b792638fb77c8d1b4ee2197b29b63922e0fe211
TN: U530-006
This is another preparation patch for the transition to Python 3.x.
With Python 3.x, we need to make sure that the input used when
calling the filer cmd is converted to a byte string. We also
then need to make sure that the script's output is decoded into
a string.
Change-Id: I324410dd5c9b1e811252803b854d0f06ca65435d
TN: U530-006
This commit is part of the prep work for the transition to Python 3.x,
where the input of the hooks need to be encoded before send it,
and where the output needs to be decoded.
Change-Id: I68fa9de5b4c8b932f931725174a6424716855c2a
TN: U530-006
This is another preparation patch for the transition to Python 3.x,
where the input first needs to be encoded before it is passed to
the git command to be executed.
Change-Id: I2d8aac02a17b5d5765ab5e2c357bc15ead4f2c64
TN: U530-006
This is another preparation patch for the transition to Python 3.x.
The script's input needs to be encoded when called, and its output
needs to be decoded into a string for us to process it.
For input encoding, the same approach as for decoding is taken:
In order to make progress towards Python 3.x support while at
the same time preserving support for Python 2.x, we introduce
a new function "encode_utf8" which only performs the encoding
on Python 3.x. With Python 2.x, the function just returns the string
unmodified.
Change-Id: Ieb47d32c756405cdd0d300254e8cd7c8c3db50b5
TN: U530-006
This commit is preparation work for the transition to Python 3.x,
where the output obtained by running Git commands will become
bytes as opposed to a string. In the vast majority of cases,
we'll want to decode that output into a string. Ideally, we would
want to do this in a way that is both compatible with Python 2.x
and Python 3.x, but we have found that this requires a lot of
work with many changes spread all over the code. So, instead,
what this commit does is introduce the concept of decoding
the output, but with the decoding only occurring when running
under Python 3.x.
That way, we can make progress towards Python 3.x while preserving
the behavior under Python 2.x intact.
Change-Id: I189577798ee96cba1fa55c7356babf102575642f
TN: U530-006
