[IMP] less volatile reference databases #859
Merged
Conversation
This file contains 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
Xavier-Do
changed the title
Xavier-Do
force-pushed
the
17.0-upgrade-rebuild-params-xdo
branch
4 times, most recently
from
fbdd32d
to
eae1dcf
Compare
Xavier-Do
changed the title
Xavier-Do
force-pushed
the
17.0-upgrade-rebuild-params-xdo
branch
4 times, most recently
from
c749ef9
to
51feeb0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
One a new batch is triggered, even if the commit head didn't change, the upgrade builds a frequently restarted because the reference builds are not the same once one of them changed.
It's not a big issue, but it can generate useless load when passing pr from draft to ready for review, or starting a new batch manually, ...
This pr proposes to have reference batches on each base branches, that will be used as reference by dev branches instead of taking the last one.
The idea to search the latest batch created before the base batch was considered, but this won't work well for freshly rebased branches since the last done may change. The easiest solution is to store all last done base batch on each base bach.
The question ss, should we filter them per category?
1- before storing them?
2- store all of them and filter when needed
The actual state of the database would make 1 more logical, but looking at the current code it is possible to upgrade from the trigger from another category (use nightly databases)
This will only contains the model change, logic change will be contained in #869 to allow an incremental testing of changes