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
This script, which is used as a replacement for sendmail when
running the testsuite, has two modes. In the default mode,
it currently does nothing more than dumping to standard output
the email being asked to send.
This commit changes the script to parse the email instead, and
dump its contents once parsed, rather than dumping the email
as is. The dumping is written so to keep the output the same.
The goal is to help print the email body in a human-readable way
regardless of its content transfer encoding. This will become
particularly useful when we start using base64 content transfer
encodings.
This is tied to the transition to Python 3.x, where the email
support classes automatically chooses base64 transfer encoding
in some cases. More generally speaking, we have plans to use
base64 more often, as this format ensures that we do not exceed
some limitations in email transport (maximum line length, for
instance).
TN: U530-006
Change-Id: I645126470e8a3b944ff668aba6d30381d418c6b1
The goal of this commit is to include the updates.sendmail module
in our testing strategy, in order to make sure that the hooks are
passing email data down to the sendmail program without issues.
This will become particularly important when we switch over to
using Python 3.x, because of the strong distinction between bytes
and strings with newer versions of Python which can cause a lot
problems. Hence the need to use this code during our testing.
The main strategy introduced by this commit to achieve this is
fairly simple: The testsuite framework introduces a new minimal
script to be called in place of the standard sendmail. A new
environment variable called GIT_HOOKS_SENDMAIL is introduced
allowing the testsuite to tell the hooks to use its own (fake)
sendmail instead of the system one. With that in place,
the old code bypassing the use of updates.sendmail can be removed,
thus allowing the testsuite to include it as part of the testing.
The testsuite's (fake) sendmail script was written in a way to
mimick the old bypassing code, so there is no change in output.
Parallel to that, the hooks are enhanced to check that we can
indeed find sendmail, and otherwise return immediately with
an error if not. This way, we avoid emails silently being
dropped due to the missing sendmail.
A couple of testcases are also added to double-check some
specific error situations.
Note that I tried to think of ways to split this patch into
smaller individual parts, but couldn't really find a way to
do so in a meaningful way, while at the same time producing
a commit where the coverage report stays clean (0 lines missed).
TN: U530-006 (transition to Python 3.x)
TN: U924-032 (test for sendmail not found)
TN: U924-034 (test for sendmail override when in testsuite mode)
Change-Id: I74b993592ec6d701347bbca5283a42e037411f1c
These testcases are testing the git-hooks behavior when using
a commit-extra-checker hook. This hook works by receiving info
about the commit to check via stdin, as a dictionary in JSON format.
To help the testcase verify the data being passed via its stdin,
the hook currently prints the contents of stdin verbatim.
Unfortunately, this makes an unwarranted assumption about
the order of the elements in that string representation,
causing spurious differences when trying to run this testcase
with Python 3.x.
This commit enhances the scripts used by these testcases to
output the contents of the data in a way which is always
the same, regardless of the order it was passed in.
TN: U530-006
Change-Id: Ia8b16611bb29b7601f14949ee5554c906b947853
This commit slightly rewrites the way we format the expected output
of our of our tests, by using the "format" method instead of using
the "%" operator. It doesn't make much of a difference, at the moment,
but this will become handy when we transition to Python 3.x, where
the "No such file or directory" error now includes the path of
the file/directory that's missing.
TN: U530-006
Change-Id: I748ca76d411cfdf79dd33402d1297e7372decc38
While testing the behavior of the git-hooks under Python 3.x,
I noticed that the order of some output was not the same as
when running it with Python 2.x. When investigating further,
I found that the order with Python 2.x made better sense, and
that the different order was caused by stdout/stderr buffering.
This commit turns buffering off entirely in an effort to make
sure that output sent to stdout & stderr gets seen in the order
that it was sent.
As it happens, while this commit was aimed at Python 3.x,
running the testsuite showed that we had one testcase where
the order when using Python 2.x was also incorrect, and
therefore misleading, for a couple of tests. The tests'
expected output was double-checked, and adjusted accordingly,
with additional comments explaining what each part was about.
TN: U530-006
Change-Id: Iaf2c5266e13a645dab006e1f7f4cb553cbd5704f
Type "basestring" is does not exist with Python 3.x, so this commit
removes it from this testcase.
TN: U530-006
Change-Id: Ic53b269c29c90f686a2fb7b834215b22454cd6c0
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: Iac2f64e6574bf0de13a001b54f095bf2b90e751e
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: Iecf941468e5c13a59d377fa2d2601a7b0e9baf09
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: Id6fa5938acf7edc75b9109c427b3175b07806cda
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I85dff8dde0ce92cc167cddf908a47d6fef40b9d1
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I4ac573ea7a92d1843e171f55f84264bff4cdcd7c
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I5d6e84b194801fc21a7811ddf74417622755b233
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I933c12b325a9aaca10bcaaa48ab98f31416c9b2e
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: Ibff975590a86352be3d88e0abccdff1478c29280
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I983cedbe910566ee8b6380658071c71cce61f1c8
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: Ida6af557c5410febcf2c36349d7a49626be71dbc
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: Ic1fea1b5133dcc341f8fd6e6a1a8df339a754d22
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I43d3708a659bf2ccb488e5b91a8f5dce4bcba60d
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I471342a22ef1ecfb5befc10d910acf3461be1e83
The testcase was working without before, but that was only by
chance, because we're doing a wildcard import of the support
module. Since that module will disappear when we transition
the testsuite to pytest, best to import os explicitly now.
TN: U530-006
Change-Id: I8a779f8a7df583518f2ff38a5c2a527668a2fb40
