commit | 24369c8d9c4ed694d41080c4afdb1c5ce2eb163f | [log] [tgz] |
---|---|---|
author | Marco Miller <marco.miller@ericsson.com> | Wed May 27 15:45:48 2020 -0400 |
committer | Marco Miller <marco.miller@ericsson.com> | Wed May 27 16:20:53 2020 -0400 |
tree | 717b91a157baf4d0fd020e940e67c8c768c65e4f | |
parent | e2872f3b1e7e888852a6497489b066a923d62fbd [diff] |
e2e-tests: Add {Approve|Submit}Change core scenarios Add an ApproveChange scenario and base the SubmitChange scenario on it. Make the ApproveChange scenario runnable alone as well. In this case, allow the change number being approved to be set through the existing 'number' test environment property; cf. [1]. In the other case of running approval from SubmitChange, set the change number automatically. Adapt the existing standalone DeleteChange scenario, for SubmitChange. That scenario showed to be very similar to the added ApproveChange one. Adapt the existing standalone CreateChange scenario, so it can be run from SubmitChange now as well. Make the CreateChange project field no longer automatic or solely set by CreateChange alone. Instead, make it either set from composing scenarios such as SubmitChange or as per [1]. Enable this all by making CreateChange a core ProjectSimulation now. Rather than having DeleteChange hold the change number, move it to the CreateChange class. Enable this new SubmitChange scenario flow that way, while preserving existing scenario abilities. Having the CreateChange scenario generate *and* hold the resulting change number should also be more intuitive, compared to DeleteChange holding it before. [1] https://gerrit-documentation.storage.googleapis.com/Documentation/2.16.19/dev-e2e-tests.html#_environment_properties Change-Id: I86dda57672ef9f34a286bfd151226b5988cb7a34
Gerrit is a code review and project management tool for Git based projects.
Gerrit makes reviews easier by showing changes in a side-by-side display, and allowing inline comments to be added by any reviewer.
Gerrit simplifies Git based project maintainership by permitting any authorized user to submit changes to the master Git repository, rather than requiring all approved changes to be merged in by hand by the project maintainer.
For information about how to install and use Gerrit, refer to the documentation.
Our canonical Git repository is located on googlesource.com. There is a mirror of the repository on Github.
Please report bugs on the issue tracker.
Gerrit is the work of hundreds of contributors. We appreciate your help!
Please read the contribution guidelines.
Note that we do not accept Pull Requests via the Github mirror.
The Developer Mailing list is repo-discuss on Google Groups.
Gerrit is provided under the Apache License 2.0.
Install Bazel and run the following:
git clone --recurse-submodules https://gerrit.googlesource.com/gerrit cd gerrit && bazel build release
The instruction how to configure GerritForge/BinTray repositories is here
On Debian/Ubuntu run:
apt-get update & apt-get install gerrit=<version>-<release>
NOTE: release is a counter that starts with 1 and indicates the number of packages that have been released with the same version of the software.
On CentOS/RedHat run:
yum clean all && yum install gerrit-<version>[-<release>]
On Fedora run:
dnf clean all && dnf install gerrit-<version>[-<release>]
Docker images of Gerrit are available on DockerHub
To run a CentOS 7 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-centos7[:version]
To run a Ubuntu 15.04 based Gerrit image:
docker run -p 8080:8080 gerritforge/gerrit-ubuntu15.04[:version]
NOTE: release is optional. Last released package of the version is installed if the release number is omitted.