chore(e2e): Init end to end next project#1782
Draft
noaccOS wants to merge 1 commit intoastarte-platform:release-1.3from
Draft
chore(e2e): Init end to end next project#1782noaccOS wants to merge 1 commit intoastarte-platform:release-1.3from
noaccOS wants to merge 1 commit intoastarte-platform:release-1.3from
Conversation
noaccOS
force-pushed
the
push-rskplkumsyno
branch
11 times, most recently
from
5495678 to
52e9b8d
Compare
This is a re-implementation of the e2e project from the ground up ### Motivations The end to end tests are currently used as two separate tools independently: - by astarte, to run end to end tests - by the platform team, to perform synthetic monitoring End to end tests have previously been rewritten in order to perform a better job for astarte tests, but in the process it was made unusable as a synthetic monitoring tool. As the current status of the e2e project is still not ideal, we can take this chance to re-think its design from the ground up, as the current e2e implementation still has a few problems: - sometimes it just crashes - it's hard to track what goes wrong once things crash - the elixir device sdk is not used in production, and doesn't offer modern features (such as FDO) - reworking the current e2e to allow it to be used as a synthetic monitoring tool would imply a major rewrite nonetheless ### Design choices First and foremost, this is written in Rust. This is because at the present time the Rust Device SDK is the most complete SDK implementation and one actually used in production, and we already depend on Rust code for the FDO end to end tests. Future developments will also be available in the Rust SDK, so this project will be easily extendable. The project now compiles to a binary, whose only job is to be used as a Synthetic Monitoring tool. At the present time, it offers only data-path checks through volatile triggers, just like the old e2e test did, but it will be extended later to allow other checks currently available in the current e2e. The e2e tests are defined as `test`s in application binary, as cargo already offers a nice ux to track... tests. This makes the code path separate from the synthetic monitoring usage, while still sharing all the code. Unlike the current e2e test, this tool will not offer mail alerts, and in order to receive alerts, a prometheus and alert manager stack will need to be deployed Signed-off-by: Francesco Noacco <francesco.noacco@secomind.com>
noaccOS
force-pushed
the
push-rskplkumsyno
branch
from
52e9b8d to
bbf671f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a re-implementation of the e2e project from the ground up
Motivations
The end to end tests are currently used as two separate tools independently:
End to end tests have previously been rewritten in order to perform a better job for astarte tests, but in the process it was made unusable as a synthetic monitoring tool.
As the current status of the e2e project is still not ideal, we can take this chance to re-think its design from the ground up, as the current e2e implementation still has a few problems:
Design choices
First and foremost, this is written in Rust. This is because at the present time the Rust Device SDK is the most complete SDK implementation and one actually used in production, and we already depend on Rust code for the FDO end to end tests. Future developments will also be available in the Rust SDK, so this project will be easily extendable.
The project now compiles to a binary, whose only job is to be used as a Synthetic Monitoring tool. At the present time, it offers only data-path checks through volatile triggers, just like the old e2e test did, but it will be extended later to allow other checks currently available in the current e2e.
The e2e tests are defined as
tests in application binary, as cargo already offers a nice ux to track... tests. This makes the code path separate from the synthetic monitoring usage, while still sharing all the code.Unlike the current e2e test, this tool will not offer mail alerts, and in order to receive alerts, a prometheus and alert manager stack will need to be deployed