Our company-internal Gerrit uses federated logins (Shibboleth/SAML), and
the login names happen to include the at-signs. This needed a patch to
Gerrit ([1], released in 2.13.10) to allow them. Cloning using regular
git tools as well as through the gertty work, but `git-review --list`
complained because it couldn't parse these URLs.
[1] https://gerrit-review.googlesource.com/c/94914/
Change-Id: I6c1c75a585184ee3fb2847c1e6d30802e53f8b4c
When something is not found in git config, the --verbose option logs the
wrong value "None", example:
2018-12-12 Running: git config --get gitreview.branch
2018-12-12 using default: None
2018-12-12 Running: git config --get gitreview.scheme
2018-12-12 using default: None
2018-12-12 Running: git config --get remote.gerrit.pushurl
2018-12-12 using default: None
2018-12-12 Running: git config --get remote.gerrit.url
2018-12-12 result: ssh://marc@review.openstack.org:29418/openstack-infra/git-review
From a --verbose user perspective this is plain wrong for (at least) all the
options defined in the DEFAULTS list.
Change --verbose message to look like this instead:
2018-12-12 Running: git config --get gitreview.branch
2018-12-12 Config['branch'] = master
2018-12-12 Running: git config --get gitreview.scheme
2018-12-12 Config['scheme'] = ssh
2018-12-12 Running: git config --get remote.gerrit.pushurl
2018-12-12 Running: git config --get remote.gerrit.url
2018-12-12 ... remote.gerrit.url = ssh://marc@review.openstack.org:29418/openstack-infra/git-review
If git_config_get_value('new_option',... ) is ever invoked in the future
with a not None, default="fubar" parameter then --verbose will print these
lines:
2018-12-19 Running: git config --get gitreview.new_option
2018-12-19 ... nothing in git config, returning func parameter: fubar
This logging issue is especially misleading considering the many levels of
defaults and fallbacks: git config x3; .gitreview; DEFAULTS list,
git_config_get_value(default=...) parameter, options parser logic, etc.
Change-Id: I6cee46e88b90b8f11689be3875d64ec5e577f12f
Newer versions of git quote branch names in their output; at least git
2.16.3 does. This causes all test_uploads_with_nondefault_rebase tests to
fail like this:
testtools.matchers._impl.MismatchError:
'Branch test_branch set up to track remote branch maint from origin.'
not in
u"Switched to a new branch 'test_branch'\n\
Branch 'test_branch' set up to track remote branch 'maint' from 'origin'."
Add a testtools.matchers.MatchesRegex() to support both styles.
Change-Id: I9f1417c53de2f7d638e845f553df3bd426a4c750
From: https://www.openssh.com/txt/release-7.8 change log:
* ssh-keygen(1): write OpenSSH format private keys by default
instead of using OpenSSL's PEM format. The OpenSSH format,
supported in OpenSSH releases since 2014 and described in the
PROTOCOL.key file in the source distribution, offers substantially
better protection against offline password guessing and supports
key comments in private keys. If necessary, it is possible to write
old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
when generating or updating a key.
This fixes all tests failing with this error:
[2018-12-04 17:46:24,130] WARN org.apache.sshd.common.keyprovider.FileKeyPairProvider :
Unable to read key /home/mherber2/pip/src/git-review/.gerrit/site-5123/etc/ssh_host_rsa_key
java.io.IOException: unrecognised object: OPENSSH PRIVATE KEY
at org.bouncycastle.openssl.PEMParser.readObject(Unknown Source)
at org.apache.sshd.common.keyprovider.FileKeyPairProvider.doLoadKey(FileKeyPairProvider.java:124)
Change-Id: Id10f9b5be928f2ba57847fa32814e9db979375f5
Python2 has default encoding as ascii which means
that is likely that some print() commands would
fails with UnicodeEncodeError.
This hack changes default encoding in order to
avoid such errors.
Change-Id: I4e21e6e32d4bb815693b7d6ce35efb6a5cca2fc2
Refactoring to improve code style as suggested by pep8.
- "rc" and "status" variables cannot be None beacause the process is
terminated after the "run_command_status"
- It's better to ignore an empty "username"
Change-Id: I8a34f4ab9e05d91786ce6d62e4db96811787b633
Unnecessary dynamic GitReviewException.EXIT_CODE attribute
lookup refactored into static to benefit static analyzers.
Default process exit code changed from 127 (command not found error)
to 1 (general error)
Change-Id: I1fcb583a740bf32c4427a587e208d099712a7bc4
The feature to configure branch names based on the presence of "bug",
"lp", "blueprint" or "bp" in the commit message is overly elaborate and
very OpenStack specific. Even with this, it hasn't been updated to keep
up with the times as many projects have migrated to Storyboard, which
isn't handled here.
Given that it frequently does the wrong thing and likely doesn't apply
to anyone outside of the OpenStack ecosystem, the wisest thing it to
simply remove the feature. This is a break in behavior but it seems
better than adding yet another flag for something that many users will
want enabled by default.
Change-Id: I82ecc1719de5c87d59bbfe73a042917e6559da1e
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Story: 1130330
Task: 566
Story: 2001247
Task: 5777
This was brought up by an RPM lint checker. It complaned about
a non-script being executable. Apparently the shebang was not
removed when we went all PBR.
Change-Id: I60098f334d136fe98d3492a3578516310e31296c
fetch_review was updated to take project config information so that
projects hosted over http below some root (eg
https://gerrit.org/gerrit/here) could be properly fetched against. But
in adding this we broke the compare_review functionality which is the
other user of fetch_review.
Fix this by passing project config info into compare_review so that it
can pass that along to fetch_review.
Additionally we need to compare like types when looking at patchset
numbers so coerce them to ints when comparing.
Change-Id: I98fbf31821dc3a9162700725dec07bc7685ea5ca
Rather than requiring verbose to be specified when testing remote URLs,
always print the failure case to allow easier debugging, for example,
with unsigned CLAs.
Change-Id: I37e2d8b6b70a573a4a3f9091205d31100e3bf9f2
The old syntax is undocumented and slated to be removed.
Uniformize handling of % options. Previously, combining options could
yield destination refs that look like
refs/for/BRANCH%wip%private
which tries to switch on a non-existent option "wip%private".
Change-Id: Ia4e97eafbf685fcba78d95370dae08254a2c718b
According to latest Gerrit documentation, 2.15.3, refs/for/'branch'
should be used when pushing changes to Gerrit. Change the default
behavior to refs/for/* instead of refs/publish/* which has been
deprecated. This removes a warning from Gerrit remotes running the
latest version when pushing changes without commandline options.
Change-Id: Ibaddfda96457a72c54ca9c91a8ad25d14b88c582
Rather than forcing users to copy only part of a URL to a review, allow
them to paste the whole URL and then parse it for them to find the
change id.
Change-Id: Ic012c86b2b477d17354bf8d119e1d4b698378dd7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
Show the syntax for requesting a specific version of a patch.
Change-Id: Id72935c715a7b5c17722400dde6175b99e61860b
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
In Gerrit 2.15 two new workflow states(`work-in-progress` and
`private`) are introduced. This patch tries to implement them.
Gerrit documentation says:
To push a private change or to turn a change private on push the private
option can be specified:
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%private
Omitting the private option when pushing updates to a private change
doesn’t make change non-private again. To remove the private flag from a
change on push, explicitly specify the remove-private option:
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%remove-private
To push a wip change or to turn a change to wip the work-in-progress
(or wip) option can be specified:
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%wip
Omitting the wip option when pushing updates to a wip change doesn’t
make change ready again. To remove the wip flag from a change on push,
explicitly specify the ready option:
git push ssh://john.doe@git.example.com:29418/kernel/common HEAD:refs/for/master%ready
https://gerrit-documentation.storage.googleapis.com/Documentation/2.15/intro-user.html#private-changeshttps://gerrit-documentation.storage.googleapis.com/Documentation/2.15/intro-user.html#wip
Change-Id: Ia093e4a691fa8eb17c798473a79a97694202fd03
It seems the "number" field returned via gerrit JSON can be a string
(2.13) or a integer (~2.14). Ensure we can handle both.
Change-Id: I3cbda6c07343332aba592bd96fd8545f08a2cbfe
I'm not sure what print_safe_encoding is trying to do
(Ie834931a549175471af029a6ec4d5794543d8c92).
print(str.encode(sys.stdout.encoding, 'replace'))
means that print() ends up getting a bytes-object encoded in the
output encoding. Thus print() is then going to output this as raw
bytes... not only is unicode going to come out as "\x..\x.." etc, but
even newlines get squished and you end up with stuff like
$ /tmp/gitreview3/bin/git-review
b'remote: \rremote: Processing changes: updated: 1, refs: 1\rremote: Processing changes: updated: 1,
I think this problem stems from not ensuring that incoming data
(output of git) is encoded as a string. By setting
universal_newlines=True in run_command_status() we automatically
ensure that any incoming data is a unicode str, not bytes.
The final section, with the message about rhbz#1058167, appears to be
related to running git under an alternative locale where it's output
is translated. I1bf1124f0b09d6658a7b0703e3b9e74ed80f4eea changed
things to run the commands under C locale, so there shouldn't be
unicode in here I wouldn't think. But, by ensuring it's just a
string, we can print() it safely anyway.
Change-Id: I596dcba317ecfbaf437cb72d9850580ed6765fce
Previously git review could not properly query Gerrit servers via http
if the root of the Gerrit api was below /. This is because it was always
rooting the changes query api at /changes instead of /foo/changes if
hosted at /foo.
To fix this we read the project name from the config so that we can
remove the project name suffix from the urls then append changes/ to the
resulting url to get a properly rooted query url.
Note this was never a problem with ssh because ssh can't be hosted as
some subpath. Everything is rooted with ssh and gerrit.
Change-Id: I46e21dfdbbb7f60aa89a7b028501c0d953ae1d7f
The 2.15 release of git drops support for `git branch --set-upstream`
and replaces it with `git branch --set-upstream-to` which was added in
git 1.8. Move from --set-upstream to --set-upstream-to in order to
support git 2.15 and beyond. Note that this specifically affects the
`git review -d` functionality as it is what needs to update the
upstream.
This does drop support for git 1.7 and older though as this option did
not exist then. Polling linux distros and OS X the oldest git I can find
is on CentOS 7 which has 1.8 so this should be fine.
Story: 2001266
Co-Authored-By: Harry Mallon <Harry.Mallon@codex.online>
Change-Id: I5ded1ab39bb2c76bdc38655299bac11b4584e138
We show the command used to retrieve the config value, but don't show
what we find. Fix that, and also show cases where we are going to use
the default setting.
Change-Id: I53ee9ea6e3af4e951587c0845c8333874238f0c2
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The SSH query API changed from 2.13 to 2.14 from
{"number":"1", ...}
to
{"number":1, ...}
so we need to stringify everything in order to do len, encode etc. on
it.
Change-Id: I06bdd1b4b1181d00a27ce1e76f97baed8cde1284
Story: 2001095
Split the displaying of reviews into a separate class to make it easier
to alter the output and accommodate different display options.
Change-Id: I6007259686fc15ae21ae6843faa4ff7ad545cef1
Now you can pass multiple '-l' options like '-ll' and when doing so, it
will show also the topic of the patches
Change-Id: Iabc1107d66a17fde751f90d7fa33f15fe54c7f58
Signed-off-by: David Caro <dcaroest@redhat.com>
Co-Authored-By: Darragh Bailey <dbailey@hpe.com>
Convert to using python format to align and interpolate values to
ensure the correct output on python 2 & 3 when dealing with unicode and
str.
Interpolating strings using encode into '%s' and subsequently
interpolating the results into a second string results in the output
printing embedded byte strings on python 3.
$ git-review -l
b'226894' b'master' b'Add pem key parameter (WIP)'
b'199225' b'master' b'support urls as change-id input
Which occurs because after converting a string to unicode bytes, it was
then interpolated using '%s'.
Switching to using '.format()' method takes care of converting the
output to the correct string format for python 2 & 3 automatically.
Change-Id: Ia962d18bda34e0244fb05636a7be263045ecb256
