eiffel-community / eiffel-gerrit-plugin Goto Github PK

By requesting a plugin repository on gerrit-review [1] and moving the plugin development there you can leverage the Gerrit community expertise and infrastructure (version compatibility, test, build, ...) and make the plugin more available to everyone.
F.i.

• This plugin is only built with maven whereas Gerrit and all "official" Gerrit plugins are built with Bazel,
• This plugin is built against Gerrit v2.14 whereas the currently oldest supported version of Gerrit is 2.15, and even 2.15 is planned to reach EOL in November [2].

BR
Sven

[1] https://gerrit-review.googlesource.com/admin/repos/q/filter:plugins
[2] https://www.gerritcodereview.com/2019-09-09-gerrit-3.1-release-and-2.15-planned-eol.html

Description

This repository currently has a .travis.yml file that triggers Travis CI builds for e.g. pull requests. On Dec 16, 2021, the Eiffel Technical Committee decided that existing uses of Travis CI should be migrated to GitHub Actions (see minutes).

Motivation

Nowadays Travis CI isn't as free to use as it used to be. There's a limited number of credits given to each organization, and right now we're fairly close to the limit. In recent years GitHub Actions has been introduced and it should be adequate for most use cases.

Benefits

Decreased risk of service interruptions if we reach the usage limit (and nobody will have to spend time on requesting increases in the limit).

Possible Drawbacks

Probably none, unless your current .travis.yml contains steps that are very difficult to replicate in a GitHub Actions workflow.

Description

As can be read in #16, the plans are to finish the first version of the plugin for gerrit api version 2.14. When that is done, we should look into how to adapt this plugin to fit with the last version of the gerrit api taking to consideration that we should continue to support 2.14 as well.

Motivation

There are different users of the plugin that requires support for different version of gerrit api.

Exemplification

Master supports latest gerrit api version.
Branch 2.14 supports gerrit api 2.14
Any other branches could support other versions of gerrit if needed

Benefits

User is not restricted to a specific gerrit api version.

Possible Drawbacks

More versions to maintain.

Description

When using the cherry-pick submit type with empty changes we will not behave correctly. Gerrit will always send Gerrit events even though the master branch is untouched. This happens when you create an empty change.

Motivation

Exemplification

This happens when you create and submit an empty change and have submit type cherry-pick. This is seen in the integration tests. Currently this integration is not part of the test suite (its commented out).

Benefits

The Gerrit plugin becomes more robust

Possible Drawbacks

Time-consuming to come up with a solution

Description

In order to get an overview of the scope of the implementation there should be an architectural overview of the different components and how they fit together(Not in the detail of input/output). This overview will then be used to create the rest of the stories for the actual implementation.

Note that we want to work agile so do not make the overview too detailed as requirements might change.

Motivation

In order to paralellize the work to different people we will need some kind of overview. This will help us have a somewhat clear picture of what we are to implement.

Description

Steps to reproduce:

• Enable the Eiffel plugin
• Remove all REMRem information
• Try to create a change via the GUI

Motivation

The 500 server error that is shown to the user is not very helpful

Exemplification

Benefits

The usability will improve

Possible Drawbacks

Description

Setup the project structure for the plugin so that it can be loaded into gerrit. The project should be based on maven as the rest of the Eiffel components.

Description

When parsing data for an SCS event user data for author is extracted from the Gerrit event instead of the submitter data.

Motivation

Correct user data extracted and put in the Eiffel event.

Benefits

Correct user information in the Eiffel event.

Dependent on #8

Investigate what configurations the GUI should provide with regards to the architecture overview seen here #6. Some configurations that should exist at minimum is:

• The enabling of event sending
• REMReM configuration
• Selection of which events you want to trigger on

Description

In order to make sure that everything pushed to master is working. There should be a travis file created to support different stages, unittesting and systemtesting. NOTE that the tests are not created at this point so it only needs to have the structure created with empty jobs.

Description

In ServiceIntegrationSteps.java line 208 the parameter account_id=1000000 is set using .setEndpoint(). This will not work when upgrading eiffel-commons to the latest version. To be able to run integarion tests after updating eiffel-commons version the account_id parameter must be set using addParameter method.

Motivation

Integration test will not work if eiffel-commons is updated to latest version.

Exemplification

Make the code look more decent.

final HttpRequest requestLogin = new HttpRequest(HttpMethod.GET, httpExecutor);

requestLogin.setBaseUrl(GERRIT_BASE_URL)
            .setEndpoint("/login/")
            .addParameter("account_id", "1000000")
            .addParameter("http.protocol.handle-redirects", "false");

final ResponseEntity response = requestLogin.performRequest();

Description

Dependent on #8

The first draft of the gerrit plugin should be able to send EiffelSourceChangeCreatedEvent and EiffelSourceChangeSubmittedEvent. According to #6 there should be some kind of mechanism to generate the Eiffel events. The factory pattern could be one such way to realize this in order to make the one generating the event less affected by future additions/changes.

On initialization of the Eiffel event, it should populate itself with relevant fields from the gerrit event(besides from the links).

As a summary, this story should implement the functionality to generate Eiffel events as well as creating the actual EiffelSourceChangeCreatedEvent and EiffelSourceChangeSubmittedEvent object.

Please see #6 for the architectural overview document.

Description

Dependent on #8
Check #6 for more information of the context.

A gerrit listener should be implemented so that we can listen for certain events that the user has described in the configuration(mock the config since config is part of another story). When an event that the user want to send has been triggered it should(if possible) create a new thread where the functionality to generate and send the event is called(the actual functionality for eiffel event generation and sending is done in another story).

Is it possible to filter before getting the Gerrit message?

Description

Dependent on #8

The eiffel events should be able to ask the state handling mechanism about the eiffel id for a specific link type by providing some input(to be decided in this story) in order for the state handler to know the current context for the link(branch etc).

This story also includes implementation of the DB handling mechanism where all the eiffel event IDs are stored. It should be possible to save and retrieve eiffel event ids.

Please see #6 for the architectural overview document.

Description

Related to issue #31
Requests are not async at the moment and we need some sort of solution for this.

Motivation

Synchronous requests to REMReM will block the listener thread. It needs to start an independent job and release the thread.

Exemplification

#32 (comment)
RabbitMQ plugin mentioned here has an implementation that could be used.

Benefits

Prevent threads from being held.

Possible Drawbacks

Description

When receiving certain gerrit events they should be assembled as serializable eiffel event objects. These objects are to be used later when generating the final eiffel event through the eiffel-remrem-generate service.
patchset-created -> EiffelSourceChangeCreatedEvent
changed-merged -> EiffelSourceChangeSubmittedEvent

Exemplification

A data structure should be created for the eiffel events and populated with the gerrit event information.

eiffelEvent.msgParams.meta.source.uri = gerritEvent.chage.get().url
...

Description

#28 (review)

Some improvemens were suggested by @tobiasake
More information needed.

Motivation

Exemplification

Benefits

Possible Drawbacks

Description

We at Nordix Community intend to start prototyping with Eiffel.

One of the aspects we want to try out is to publish SCM events (EiffelSourceChangeCreatedEvent and
EiffelSourceChangeSubmittedEvent) from Nordix Community Gerrit Instance.

However, the current version of Gerrit supported by eiffel-gerrit-plugin seems to be 2.X and we use Gerrit 3.4.1 in Nordix Community.

We are wondering if community has plans to introduce support for later versions of Gerrit API?
If so, where can we learn more about this effort and contribute?
If not, how can we contribute this support?

This issue is related to an existing issue, #25, aiming to enable introducing support for different versions of Gerrit API, however that issue hasn't received any answers yet.

Motivation

There are different users of the plugin that requires support for different version of gerrit api.

Exemplification

Communities support different versions depending on the users' needs and sometimes this support is introduced by the users themselves.

Benefits

Different versions of Gerrit can be supported, increasing the adoption of the plugin and Eiffel in general.

Possible Drawbacks

More versions to maintain.

Description

We need to implement some sort of thread safe retry handling for our requests.

Motivation

We don't want to immediately dismiss messages that don't reach REMReM.

Exemplification

Spring-retry
Spring has a solution for a retry mechanism.
CircuitBreaker pattern
CircuitBreaker Spring
Also look at circuit breaker pattern and the implementation by spring.

Benefits

Avoid lost requests.

Possible Drawbacks

It could potentially put an extra burden on resources and make the system more unresponsive.
This needs to be implemented carefully.

Description

Currently, the plugin does not have any integration tests that test end to end. Adding these tests would help to develop a stable system.

The tests would:

• Create a patch
• Make changes to the patch
• Add review verification
• Submit the patch
• Check that events sending was performed

Motivation

Gives the developer more confidence that the changes he/she make will not break anything.

Exemplification

Benefits

Automatic testing of end to end which will improve quality

Possible Drawbacks

Provide a manual on how to use the Eiffel Gerrit Plugin with information about what each configuration corresponds to.

Description

The SCC event has support to provide links to EiffelIssueDefinedEvents. There is currently no way to get such links into the SCC events sent from this plugin.

Motivation

To increase the trace-ability in source changes notified by this plugin to also include links to issues handled in the source change.

Exemplification

The commit message could contain a tag specifying what issue has been solved or partly solved with that source change. As the SCC event can contain RESOLVED_ISSUE or PARTLY_RESOLVED_ISSUE links to ID events it should be handled by this plugin. Whether the plugin should also send that ID event itself, or just lookup and link to existing ID events needs to be figured out.

Benefits

More complete trace-ability of issues handled in a source change

Possible Drawbacks

If the plugin itself would send the ID events it could be seen as a bit weird.

Description

The plugin documentation in src/main/resources/Documentation/about.md describes two different ways of dealing with multi-valued configuration keys:

• The filter key uses spaces to separate the branch name regexps.
• The flow-context key uses commas to separate message UUIDs.

The configuration file format (and the PluginConfig accessor API) supports multi-valued keys:

[plugin "eiffel-integration"]
  enabled = true
  filter = (release-).*
  filter = master
  flow-context = 971da14a-20cb-46f4-bf8f-86bb9f556499
  flow-context = 4914ed1b-15e6-48cf-9cff-841fb0c4d800
  remrem-publish-url = <URL of REMReM publish service>
  remrem-username = <REMReM Username to authenticate>
  remrem-password = <Password for the above user>

Motivation

Inconsistencies in how the plugin in configured is clearly undesirable and increases the risk of misconfiguration. An incorrect configuration in this plugin can be especially problematic since it could lead to message loss which is hard or at least annoying to fix after the fact.

Apart from the consistency argument, dealing with multi-valued keys in the standard way makes it easier for automation. For example, git-config(1) supports multi-valued keys and it's totally conceivable that one would want to bulk-edit project.config files in many projects to e.g. add or remove a branch filter or flow context ID.

Description

In order to make sure all code is written in good quality, codacy needs to be used so that each PR is validated.