You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
this is related specifically to recheck and not its extension (e.g. recheck-web).
the documentation does not mention a similar solution (e.g. possible configurations).
there are no open or closed issues that are related to this idea.
this, to my best knowledge, will not break something else.
Problem
When introducing changes to the default project files (all files within src/main/resources which are placed into .retest), the user must either delete the respective file (and potentially loose any custom modifications) or adapt the changes themselves (and we therefore must provide concise steps to replicate the changes made [e.g point to a commit]).
However, if the user did not touch these files (i.e. their content is equal to the default project files), it is save to assume that they can be replaced directly. This would remove the need for the user to replace the file themselves if they never edited these.
Solution
Terminology:
1. The old file refers to the default file before the change.
2. The new file refers to the default file after the change.
3. The project file refers to the file within the project directory .retest.
Thus it would be beneficial to have some kind of merging strategy for the project files.
Currently, the new file is only replaced if the corresponding project file does not exist.
Checksum: Save the checksum of the old file, compare it with the corresponding project file and replace with the new file if equal.
Following things should be respected:
the implementation should remain computationally cheap as this might get called a few times during a test.
any files provided from the resources folder will be accessible in standard folder form during development, but will be packaged into a jar for a production release.
Implementation Outline
The method ProjectConfiguration#ensureProjectConfigurationInitialized checks if the project has been setup before. All checks are performed here and may copy any file specified from src/main/resources to the project directory.
Additional Context
This might also be useful when considering #297 and we decide to save the provided filters somewhere on the file system.
The text was updated successfully, but these errors were encountered:
Before submission, please check that ...
Problem
When introducing changes to the default project files (all files within
src/main/resources
which are placed into.retest
), the user must either delete the respective file (and potentially loose any custom modifications) or adapt the changes themselves (and we therefore must provide concise steps to replicate the changes made [e.g point to a commit]).However, if the user did not touch these files (i.e. their content is equal to the default project files), it is save to assume that they can be replaced directly. This would remove the need for the user to replace the file themselves if they never edited these.
Solution
Thus it would be beneficial to have some kind of merging strategy for the project files.
Following things should be respected:
resources
folder will be accessible in standard folder form during development, but will be packaged into ajar
for a production release.Implementation Outline
The method
ProjectConfiguration#ensureProjectConfigurationInitialized
checks if the project has been setup before. All checks are performed here and may copy any file specified fromsrc/main/resources
to the project directory.Additional Context
This might also be useful when considering #297 and we decide to save the provided filters somewhere on the file system.
The text was updated successfully, but these errors were encountered: