eiffel-community / eiffel-gerrit-plugin Goto Github PK
View Code? Open in Web Editor NEWEiffel Gerrit plugin listens on the changes in Gerrit and sends out Eiffel events
License: Apache License 2.0
Eiffel Gerrit plugin listens on the changes in Gerrit and sends out Eiffel events
License: Apache License 2.0
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.
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
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).
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.
Decreased risk of service interruptions if we reach the usage limit (and nobody will have to spend time on requesting increases in the limit).
Probably none, unless your current .travis.yml contains steps that are very difficult to replicate in a GitHub Actions workflow.
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.
There are different users of the plugin that requires support for different version of gerrit api.
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
User is not restricted to a specific gerrit api version.
More versions to maintain.
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.
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).
The Gerrit plugin becomes more robust
Time-consuming to come up with a solution
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.
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.
Steps to reproduce:
The 500 server error that is shown to the user is not very helpful
The usability will improve
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.
When parsing data for an SCS event user data for author is extracted from the Gerrit event instead of the submitter data.
Correct user data extracted and put in the Eiffel event.
Correct user information in the Eiffel event.
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.
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.
Integration test will not work if eiffel-commons is updated to latest version.
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();
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.
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?
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.
Related to issue #31
Requests are not async at the moment and we need some sort of solution for this.
Synchronous requests to REMReM will block the listener thread. It needs to start an independent job and release the thread.
#32 (comment)
RabbitMQ plugin mentioned here has an implementation that could be used.
Prevent threads from being held.
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
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
...
Some improvemens were suggested by @tobiasake
More information needed.
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.
There are different users of the plugin that requires support for different version of gerrit api.
Communities support different versions depending on the users' needs and sometimes this support is introduced by the users themselves.
Different versions of Gerrit can be supported, increasing the adoption of the plugin and Eiffel in general.
More versions to maintain.
We need to implement some sort of thread safe retry handling for our requests.
We don't want to immediately dismiss messages that don't reach REMReM.
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.
Avoid lost requests.
It could potentially put an extra burden on resources and make the system more unresponsive.
This needs to be implemented carefully.
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:
Gives the developer more confidence that the changes he/she make will not break anything.
Automatic testing of end to end which will improve quality
Provide a manual on how to use the Eiffel Gerrit Plugin with information about what each configuration corresponds to.
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.
To increase the trace-ability in source changes notified by this plugin to also include links to issues handled in the source change.
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.
More complete trace-ability of issues handled in a source change
If the plugin itself would send the ID events it could be seen as a bit weird.
The plugin documentation in src/main/resources/Documentation/about.md describes two different ways of dealing with multi-valued configuration keys:
filter
key uses spaces to separate the branch name regexps.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>
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.
In order to make sure all code is written in good quality, codacy needs to be used so that each PR is validated.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.