-
Notifications
You must be signed in to change notification settings - Fork 49
chore: fix CI by removing examples module; remove *.db files from tests module #941
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: fix CI by removing examples module; remove *.db files from tests module #941
Conversation
…ts module Signed-off-by: Ricardo Zanini <[email protected]>
Signed-off-by: Ricardo Zanini <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not get why storing binary file is worse than spawning a new JVM.
Also the DB files were stored on purpose to check backward compatibility with previous DB versions. They are intentionally NOT generated with every run
In my opinion this PR should just contain changes on release.yaml, pom.xml (to not run the examples) and comment main method of DBGenerator.
impl/test/src/test/java/io/serverlessworkflow/impl/test/MvStorePersistenceTest.java
Outdated
Show resolved
Hide resolved
impl/test/src/test/java/io/serverlessworkflow/impl/test/DBGenerator.java
Show resolved
Hide resolved
impl/test/src/test/java/io/serverlessworkflow/impl/test/ForkedDbGen.java
Outdated
Show resolved
Hide resolved
impl/test/src/test/java/io/serverlessworkflow/impl/test/ForkedDbGen.java
Outdated
Show resolved
Hide resolved
impl/test/src/test/java/io/serverlessworkflow/impl/test/MvStorePersistenceTest.java
Outdated
Show resolved
Hide resolved
impl/test/src/test/java/io/serverlessworkflow/impl/test/DBGenerator.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Ricardo Zanini <[email protected]>
Signed-off-by: Ricardo Zanini <[email protected]>
In this PR:
Correcting the sample workflowset-listen-to-any.yamlso a listen actually waits (not completes immediately due tolisten.any: []).Generating DB samples at test time (under@TempDir) instead of committing binary DB files.Making the restore tests parameterized.Adding deterministic awaits in the DB generator to eliminate race conditions.examplesfrom release mvn command.Follow up:
To check if the desired behavior is to finish the workflow immediately onlisten.to.any: []. I believe that's the desired behavior, but it's worth checking out.Not sure how theDbGeneratorwas working before, since the sample workflow was completed immediately/having a racing condition before suspending/finishing the workflow by listening to anything empty.I created a small/raw/workaround to run the generator on a separate JVM when running the tests to avoid a collision with the file read. It's working pretty good, if you have a better idea (or any changes in the store implementation to avoid this), let me know.