eiffel-community / eiffel-remrem-semantics Goto Github PK

Description

Given the security compliance , REM component should adhere to it.

Applicable dependencies:
Uplift of gson to 2.8.9 or later
Uplift of Jackson-databind to 2.13.3
Or more If required

Acceptance Criteria:
All security related components uplifted to the latest versions.
Test cases verified for the changes done
Function test cases verified for the changes done.

Motivation

To overcome security issues

Exemplification

Benefits

Vulnerability free code

Possible Drawbacks

Description

In the template for TCT The field recipeId does not say that it's required, although it is. The template should be updated so that it is clear.

Motivation

It's hard to create an event from the template since the field is required but not stated that it is.

Exemplification

Benefits

Possible Drawbacks

Description

Today eiffel-remrem-semantics library doesn't define a unit test validating generated templates.

Motivation

Lack of the test caused that event version mismatch was overlooked, see eiffel-community/eiffel-remrem-generate#203.

Benefits

Existence of the test prevents version mismatch between event schema and corresponding generated event.

Possible Drawbacks

No drawbacks identified.

Description

Running mvn clean install -P generate-events to generate new POJO classes will remove the copyright header in all files. Given the number of affected files it's very annoying to have to skip through those changes. We should either we rid of the copyright header or make sure the file generation prepends the generated files with the desired header.

Motivation

Updating this repository as the protocol changes shouldn't be hard or require additional manual steps that can be automated.

Exemplification

N/A

Benefits

Easier to update schemas, decreased risk of mistakes.

Possible Drawbacks

None.

Description

Today the various versions are released with the same major release, so making it difficult to fix the issues identified on a protocol edition.

Motivation

We have issues with older edition that needs to be addressed and we cannot upgrade to latest edition of protocol yet.

Exemplification

Benefits

If we have branching strategy we know that the releases will be based on protocol editions and easy to fix and deliver.

Possible Drawbacks

Without the branching strategy it is difficult to align on the fixes needed to be applied on certain protocol editions

Description

The Orizaba edition of the Eiffel protocol has been released and REMReM should be updated to that edition. All events have been updated in that edition.

Motivation

The Orizaba edition includes a few interesting changes that we'd like to be able to use with REMReM.

Exemplification

N/A

Benefits

REMReM clients get access to the latest event versions.

Possible Drawbacks

None. The changes in Orizaba are backwards compatible.

Description

The library contains event template files (in src/main/resources/templates) and they don't reflect changes to event schemas (in src/main/resource/schemas/input). The templates were created for version Agen and it seems nobody touched them any more.

Motivation

The event templates should match corresponding event schemas. At least one user encounter the issue: eiffel-community/eiffel-remrem-generate#203.

Exemplification

Result obtained from getEventTypeTemplate() (endpoing /template/{type}/{mp}) cannot be used as an input to generate() (endpoint /{mp}).

Benefits

Event templates are in sync with event schemas.

Possible Drawbacks

None known.

Description

REMReM-semantics doesn't add the default domain id if not provided by the user.
This improvement has to add the default domainId if its not available

Motivation

If there is no domainId present in the event, REMReM semantics has to add the default domainId

Exemplification

Benefits

Even in the case of User is not provided the domainId REMReM-semantics will add the default domainId

Possible Drawbacks

None

Need data and Links information in the Event class that can be used to fetch information about the events.

Description

The Paris edition of the Eiffel protocol has been released (see eiffel-community/eiffel#253) and REMReM should be updated to that edition. The CD and ArtP events have been bumped from 3.0.0 to 3.1.0.

Motivation

The Paris edition includes a few interesting changes that we'd like to be able to use with REMReM.

Exemplification

We have a need to publish artifact events for multi-file artifacts and support for that wasn't introduced until the Paris edition of the protocol.

Benefits

REMReM clients get access to the latest event versions.

Possible Drawbacks

None. The changes in Paris are backwards compatible.

Description

REMReM generate does not accept the link types FAILED_ISSUE, INCONCLUSIVE_ISSUE, or SUCCESSFUL_ISSUE in the EiffelIssueVerifiedEvent.
The validation fails when adding those link types to an EiffelIssueVerifiedEvent, and gives the following error message:

{
  "message": "Cannot validate given JSON string",
  "cause": "com.ericsson.eiffel.remrem.semantics.validator.EiffelValidationException: FAILED_ISSUE,INCONCLUSIVE_ISSUE,SUCCESSFUL_ISSUE link types are invalid for the event EiffelIssueVerifiedEvent"
}

Motivation

I expect REMReM to validate according to the protocol defined here: https://github.com/eiffel-community/eiffel/blob/master/eiffel-vocabulary/EiffelIssueVerifiedEvent.md .

The missing link types should be added to the IssueVerified event approved link types.

Exemplification

Benefits

REMReM validates according to the protocol documentation.

Possible Drawbacks

None.

Description

The Event.generateMeta() method should not overwrite meta.id or meta.time if valid values already exist in the meta object passed in.
https://github.com/eiffel-community/eiffel-remrem-semantics/blob/master/src/main/java/com/ericsson/eiffel/semantics/events/Event.java#L41

Motivation

When generating an Event it is the event emitter may want to specify a specific uuid (e.g. reproducible uuid) to identify the Event. To support this presently, the event emitter needs to call the remrem-generate, parse the response and replace the id in that response. This processing overhead would be unnecessary if the the Event.generateMeta did not overwrite the id passed in.

Exemplification

reproducible uuids can be used to avoid lookups when creating Events with links. For example a ScS could have a uuid that used the VCS commit identifier as a seed. It then becomes a relatively simple task to create an Act event linked to the ScS

Benefits

Reduction in processing overhead on client
Logically consistent with remrem-generate for other fields Eiffel message

Possible Drawbacks

Description

Recently a routing key template was added to Eiffel Sepia, through PR eiffel-community/eiffel-sepia#9. REMReM should adapt to that recommendation. It is almost compatible with the current implementation in REMReM, apart from the event type field, which should contain the complete event type name and not just an abbreviated version of it. Suggestion is to provide a configuration option to REMReM to keep the "legacy" (current) strings in the event type field to be compatible with any current REMReM deployments, but with the intention to be phased out in due time. It's recommended to provide this "legacy" option as a deprecated option to highlight that this option might disappear in the future.

Documentation to update

• https://github.com/eiffel-community/eiffel-remrem-semantics/blob/gh-pages/routingAndBindingKeyConcepts.html
• https://github.com/eiffel-community/eiffel-remrem-semantics/blob/master/wiki/templates.md

Motivation

To be aligned between all Eiffel eco system tools that should share the same routing key template. Eiffel Sepia should be seen as the blueprint for interoperability between tools in the Eiffel eco system.

Exemplification

E.g. a Jenkins event consumer can more easily be configured to listen to the wanted events.

Benefits

Increased interoperability between all Eiffel event producers and consumers, as they share the same routing key template.

Possible Drawbacks

Existing Eiffel message consumers & producers using another routing key scheme needs to adapt to the new routing key scheme. The proposed "legacy" option is added to this suggestion to deal with that.

Description

Running the schema update process with mvn clean install -P process-schemas on a Unix-like platform results in the following exception:

Caused by: java.lang.IllegalArgumentException: /home/magnusbk/src/eiffel-remrem-semantics/src\main\resources\schemas\input does not exist
    at org.apache.commons.io.FileUtils.verifiedListFiles (FileUtils.java:1741)
    at org.apache.commons.io.FileUtils.cleanDirectory (FileUtils.java:1716)
    at com.ericsson.eiffel.remrem.semantics.schemas.LocalRepo.readSchemas (LocalRepo.java:46)
    at com.ericsson.eiffel.remrem.semantics.clone.PrepareLocalEiffelSchemas.main (PrepareLocalEiffelSchemas.java:194)
    at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:498)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:294)
    at java.lang.Thread.run (Thread.java:748)

This is unsurprising given the backslash-separated paths in EiffelConstants.

Motivation

The schema update process should obviously be possible to run on platforms other than Windows.

Exemplification

I'd like to be able to update the schemas from a Linux host.

Benefits

Obvious.

Possible Drawbacks

None.

Description

MsgServer.generateMsg() blindly assumes that various keys are available in the input JSON object. If one of the required keys is missing a NullPointerException will be thrown. You'll have to inspect the stack trace (if available) and correlate it to the source code to figure out what the problem was. This is true for msgParams, msgParams,meta, and eventParams.

When adding these checks I think it's reasonable to consider which keys should really be required. For example, this is smallest input document that will pass muster:

{
  "msgParams": {
    "meta": {}
  },
  "eventParams": {
    "data": {}
  }
}

Should we really require msgParams or msgParams.meta? The value of requiring a value but accepting an empty object is unclear to me.

Motivation

Giving callers reasonably detailed feedback when the input data is bad is arguably a good idea, and generateMsg() already does in some cases (a bad msgType parameter) so if nothing else it'd be nice with some consistency. This is particularly true when the bad value isn't the method parameter itself but a value accessed from the parameter; getting an NPE when you pass a null parameter is more acceptable.

Exemplification

I discovered this when I was playing around with REMReM Generate and trying to pass an empty JSON body. This resulted in a 500 error with nothing in the REMReM logs (which is a separate issue; see eiffel-community/eiffel-remrem-generate#140) and I had to hack in extra logging to get the stack trace and look in the source code to figure out what the problem was.

Description

Move the documentation from gh-pages to master branch to enable better readability.

Motivation

To enable common documentation across eiffel community.

Exemplification

Benefits

Possible Drawbacks

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.

Hi!

Have you considered using protobuf to define the protocol? I remember @d-stahl-ericsson mentioning that it was considered during initial implementation but then wasn't chosen due to the reason that I don't remember. @d-stahl-ericsson what was it?

I believe we can gain a lot from using protobuf and generating protocol definitions instead of coding classes manually

Here are few examples
https://github.com/Praqma/tracey-protocol-eiffel/blob/master/src/main/proto/eiffel_event.proto
https://github.com/Praqma/tracey-protocol-eiffel/blob/master/src/main/proto/eiffel_source_change_created_event.proto

Moreover, we will get few problems out of the list - serialization, deserialization, protocol extensions and versioning.

BR, Andrey

Description

The files generated from the schemas have been edited by hand before being committed so regenerating them from the schemas results in a huge diff even if there are no schema changes. Generated files should be committed as-is. There's a related issue with the copyright headers (#133) but let's solve that problem separately and for now and just get the current files to match the generated files, except the copyright header.

Motivation

Updating the files after a schema change should be a simple task that even could be automated. Hand-patching updates is a complete waste of time. If we want files formatted in a particular way (or whatever was the reason behind the patches) we should fix the code generator or automate the patching.

Exemplification

I tried to update the generated files to the Paris edition of the Eiffel protocol and had to spend considerable time going through the diff and the history of the git to understand why the diff was huge.

Benefits

Easier to update the generated files when new protocol changes are made.

Possible Drawbacks

None.