The Gerrit interface seems to prefer patchset over patch set, so get
consistent and just use the former in help texts and documentation.
Change-Id: I03d4b3c8fcdc0624dbf2dc48fcf8f21ecdb87135
In preparation for an upcoming release, add some release notes which
were overlooked since the last release. Also add missing bits to the
manpage, and fix the markup in two unreleased release notes while we
still can.
Change-Id: I8ddb6a36e62d36bff976455d8bfc0ac6a7230387
Dumping the user into a dirtied working tree after a failed rebase
attempt can be confusing, no matter how much contextual explanation
we provide when doing so. By default, run `git rebase --abort`
automatically so as to clean up from a failed test rebase, and then
let the user rebase again on their own if that's the state they want
to be in. Add a -K/--keep-rebase option to get the old behavior, and
mention it when we automatically abort in case the user wants to
just have git-review redo the rebase for them and leave things in
that incomplete state.
Change-Id: I7d7bfca1623a71a9b4fe445360d94fd6b039f040
With the transition from pkg_resources to importlib.metadata,
finding the version string has become more complicated. Test it so
we don't break it in the future.
Change-Id: I20526518ab75ac7b58869d4126c4b5b2bc0df541
Gerrit wants each commit message to include a unique identifier
string in a special footer line, so provides a commit-msg hook to
randomly generate and insert one. Traditionally, this file is served
directly from each Gerrit server and users retrieve it via SCP or
HTTPS to install a local copy in their clone of every repository.
Retrieving this file over the network has historically presented a
number of challenges: modern OpenSSH has deprecated the SCP protocol
while the mina-sshd library Gerrit uses hasn't implemented
compatible SFTP support, authentication failures can shadow some
clearer error handling later in git-review's workflow leading to
confusing error messages, and then there are the security concerns
with needing to trust the Gerrit server to supply a script which
will end up running locally on the developer's machine.
In order to address these problems, making git-review more robust
and secure, we embed a copy of the Gerrit upstream project's
commit-msg hook in the client itself and write that to disk by
default rather than pulling a remote copy. This approach does mean
that the user will end up with a frozen version of the script
contemporary with the git-review release they've installed (but its
function is simple and the implementation has changed very
infrequently). It may also break workflows for sites which rely on
users retrieving a customized commit-msg hook. For those reasons, a
command-line option is provided to restore the prior behavior.
Change-Id: Ia26abc781a281817115cb1cafcd5e7b78b383e39
When a hook script is not executable, Git will ignore its presence
in the hooks dir. To work around that, git-review checks the
downloaded commit-message hook to see whether it's executable and
then adjusts its permissions accordingly. This behavior has been
included since the initial release, but its naive implementation
wiped all existing permissions and then added only read and execute
for the file's owner (0o500/r-x------), leaving it set read-only.
This is overly-restrictive and can lead to minor annoyances when
deleting directories or for atypical multi-user and group ownership
scenarios due to ignoring the umask set for the process.
It is expected that, at this time, the described behavior is not
widely observed outside workflows which rely on fetching the hook
script over HTTP, as the SCP protocol preserves filesystem
permission flags from the source system, but it will have a much
broader impact in the future if git-review's default workflow shifts
away from SCP.
Replace the naive chmod implementation with one which adds execute
for anyone who already has read permission, but does not remove any
existing permissions, for example:
0o644/rw-r--r-- .. 0o755/rwx-r-xr-x
0o640/rw-r----- .. 0o750/rwx-r-x---
This new behavior should be more intuitive and less surprising for
users.
Change-Id: I48ac230df09bc802610cfef65bd9818c5b01673d
...if available. It was added in Python 3.8, and marked no-longer-
provisional in Python 3.10.
Python 3.12 no longer pre-installs setuptools in virtual environments,
which means we can no longer rely on distutils, setuptools,
pkg_resources, and easy_install being available.
Fortunately, importlib.metadata covers the one use we have of
pkg_resources.
Change-Id: Iaa68282960a1c73569f916c3b00acf7f839b9807
Since I am never sure what `-w` would do (maybe it is to raise a
warning?) and the long form `--work-in-progress` is a bit too long, add
a `--wip` long form option as an alias.
That seems to align nicely with Gerrit semantic and the `--ready`
option? I can then:
```
git-review --wip
git-review --wip
git-review --ready
```
Change-Id: I818b45d1186f8ff19ec4c77acd67839df525bc28
Newer stestr is needed to avoid failures on Python 3.11 like:
nox > stestr run --color
stestr: 'run --color' is not a stestr command.
Go ahead and uncap all the test dependencies. Also drop the pbr
addition for Python<=3.5 since we no longer test with anything older
than 3.6 anyway, and fix an exception that hacking seems to really
not want us to use.
Change-Id: I85585324c4e47d37b6de555110066fb8c29f293f
assert_one_change() would fail if it detects that HEAD exists on the
remote (on any branch at all). However, some gerrit projects are
configured to allow such reviews to be opened so long as HEAD does not
exist on the target branch. Start warning rather than failing and let
the gerrit server do its own check.
Story: 2010887
Task: 48652
Change-Id: I5040aa24d78abec31054d7eeee9f6f27ce538988
Git allows setting the SSH client via the GIT_SSH environmental variable.
Honor it in git-review as well.
Story: 1024054
Task: 537
Change-Id: I760335ebc8e45749227f4328aba9edbb52196d3b
Co-Authored-By: Dr. Jens Harbott <frickler@offenerstapel.de>
This change updates the CI testing for git-review to test with Gerrit
3.4.4 and 3.7.1. This should give us good coverage of new and old Gerrit
behavior when making changes to git-review.
Note we leave 3.4.4 as the default in the test suite for local runs to
try and limit possibility of breaking old Gerrit when adding features to
git-review for new Gerrit.
Change-Id: I4a42eddec1e247cbb0af5e74b8f1cee0ad58a79a
This bumps the newest python version tested to 3.11 and drops testing
for 3.7, 3.8, and 3.9. We only test the lower and upper python version
bounds.
We switch to an ed25519 ssh key instead of rsa because Ubuntu Jammy
defaults to rsa + sha2 and Gerrit 3.4.4 does not understand this. This
results in a golden site version bump.
Change-Id: I3989460575fa9c389233244683318a6cfded68fe
Recent tox releases have put us on a config treadmill. Avoid these
issues entirely by using nox. Nox is a tox alternative that uses
standard tools like pip and should be simpler to use for us.
Change-Id: Ie79845bbed7ca1254aec466bd5219186fefcdac9
In adapting the integration tests to output from new Gerrit
versions, we observed possible nondeterministic ordering or content
in some of the fields. We don't need to be nearly so specific in the
strings we match anyway, so simplify them for robustness against
variable output from the service and improved future flexibility.
Change-Id: Icbd70d9c8c9da3637cfa5722a636d140597fe623
An addition has been proposed to leverage Gerrit's "Cc" feature, but
in order to test this we need a newer version of the server.
Newer Gerrit versions require HTTP basic auth instead of digest for
the REST API, so switch our tests to use that when uploading SSH
keys.
A newer JDK (11) is required, but this version should still be
available on our configured test platforms.
We update the test Gerrit server config to not try to send email. This
prevents annoying tracebacks from ending up in the Gerrit logs on test
failures.
We update test_cloned_repo and test_multiple_changes to look for strings
that newer Gerrit emits on successful push. Git review passes these
through to users and the tests look for them to determine if pushes were
successful.
Because of an SSH host key negotiation regression in 3.4.5, stick
with 3.4.4 for now:
https://bugs.chromium.org/p/gerrit/issues/detail?id=16215
Finally we remove skipsdist from tox.ini so that `which git-review` can
find git-review installed to the test venv. Tox v4 won't install the
project into the venv if skipsdist is set.
Change-Id: I540950b93356b1efbc34bca976bfb3134f47a599
The default nodeset has switched from focal to jammy, so we need to pin
the jobs that require focal to the correct nodesets.
Change-Id: I6d8dad4c4a4cbfa3a395b2f8a5e40f6717878a8b
There has been a long-standing misconception that git-review pushes
automatically rebased changes by default. It does not, but our
documentation and context help have been less than clear on that
point, contributing to this impression. Try to do a better job of
explaining that the default rebasing performed by git-review is
purely exploratory, and used only to notify users about possible
merge conflicts with their target branch before pushing a change.
Change-Id: I3c841af5ff9430a0de4d9dc9526dd3be6ab53ad2
Change I40356ee81b98c1210de348e51335a20be48bec1d fixed this, but was
missing a release note. Also close the story task with this change
since the other one didn't.
Change-Id: Ia27d930bf0ecefe1c26c00d6a5e93136fd120964
Task: #45100
We normally publish documentation updates in the promote pipeline,
using documentation built in the gate. As a result, the published
docs tend to lag behind release events until the next post-release
change lands. Run a separate docs build and publish it on release,
so that release notes and version information included in the
documentation reflect the most recent tag prior to the next change
merging (which for stable projects like this one, could be a while).
Override the tag jobvar to force publication to the branch path
rather than using a version-specific tree.
Change-Id: Ibf1ecfa0420a3c170beb79c14a9a9ef13fea9046
Depends-On: https://review.opendev.org/838525
Apparently Apple's `git --version` provides different output than
Linux's. Improve the version parsing by splitting on all whitespace and
taking the exact element that should be the version out of that rather
than relying on the version we want being a suffix of the command
output.
Story: 2010002
Change-Id: I40356ee81b98c1210de348e51335a20be48bec1d
Id4528209f1cd500afd06e2e61eb5689022251118 introduced a minimum git
version. Abstract our existing check and setup a global with the
local git version for tests. Add a minimum version check.
Change-Id: I9d1de11269758a453ecc8dde0a4c631d8e762a91
When a commit is signed and the git config contains the setting
log.ShowSignature=True, even the "--oneline" git log output for it will
include multiple lines (the output from gpg verifying the signature),
thus fooling us into assuming that multiple commits are to be submitted.
Override the option to make sure we always get one line per commit only.
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: Id4528209f1cd500afd06e2e61eb5689022251118
An upcoming change needs a feature from Git 2.10, which Ubuntu 16.04
LTS lacks. Since Python 3.5 reached end of life with the 3.5.10
release on 2020-09-05, it's been unsupported by its maintainers for
nearly 2 years anyway.
Change-Id: I0369c29baa344c4dc76eaa47b3467b6117eb933c
Neither the CommandFailed nor ChangeSetException classes have
docstrings, so self.__doc__ is initialized to None and can't be
trivially combined with other strings (nor would there be any point
in doing so). Just drop these unnecessary references.
Change-Id: I1f17325baa69522a4471f5bcf270a74038ad8642
The author-email and python-requires options are deprecated by
SetupTools in favor of author_email and setup_requires and trigger
warnings now, so update them. The license_files option (since its
introduction) automatically includes LICENSE and AUTHORS if not
specified, so was always redundant and unnecessary. The warnerrors
option for PBR was for Sphinx integration, which we don't use any
longer, and is ignored by modern PBR versions anyway so clean it up
too.
Change-Id: Ic5d1e17dd4926eea4e5b6fff47295fd8e9eb452d
OpenSSH has deprecated its use of scp/rcp protocol in favor of SFTP,
which the embedded Apache mina-sshd in widely-deployed Gerrit
versions does not yet support. The default officially changed in
OpenSSH 9.0 (some distributions, such as Fedora and CentOS, switched
their default behavior to this as early as OpenSSH 8.7 or 8.8),
leading to a ``subsystem request failed on channel 0`` error during
commit-msg hook retrieval. Now git-review will attempt to detect
whether scp's -O option is available to force use of the legacy
scp/rcp protocol, and apply it if so.
Change-Id: Ib64c03c3e12a3a8390e38f6ca9393db3b3c2a9e3
Jeremy Stanley