Prune one at a time up to the limit#157
Merged
mtelvers merged 1 commit intoocurrent:masterfrom Jun 7, 2023
Merged
Conversation
This was referenced Jun 21, 2023
Closed
benmandrew
added a commit
to benmandrew/opam-repository
that referenced
this pull request
Jan 31, 2024
CHANGES: - Add a Docker backend for Windows and Linux jobs. (@MisterDA ocurrent/obuilder#127 ocurrent/obuilder#75, reviewed by @talex5 and @tmcgilchrist) - Add FreeBSD sandbox backend using jail(8) (@dustanddreams ocurrent/obuilder#156 ocurrent/obuilder#174, reviewed by @tmcgilchrist, @MisterDA, and @mtelvers) - Add Macos ZFS sandbox (@mtelvers ocurrent/obuilder#164, reviewed by @tmcgilchrist) - Support XFS store (@mtelvers ocurrent/obuilder#170, reviewed by @tmcgilchrist) - Search for bash rather than assume it lies in /bin (@dustanddreams ocurrent/obuilder#159, reviewed by @tmcgilchrist) - Prune builds one at a time up to the limit (@mtelvers ocurrent/obuilder#157) - Specify upper bound on number of items in the store (@mtelvers ocurrent/obuilder#158, reviewed by @MisterDA) - Fix case where BTRFS is not fully allocated (@mtelvers ocurrent/obuilder#162) - Avoid pruning parent cache objects (@mtelvers ocurrent/obuilder#176, reviewed by @tmcgilchrist)
nberth
pushed a commit
to nberth/opam-repository
that referenced
this pull request
Jun 18, 2024
CHANGES: - Add a Docker backend for Windows and Linux jobs. (@MisterDA ocurrent/obuilder#127 ocurrent/obuilder#75, reviewed by @talex5 and @tmcgilchrist) - Add FreeBSD sandbox backend using jail(8) (@dustanddreams ocurrent/obuilder#156 ocurrent/obuilder#174, reviewed by @tmcgilchrist, @MisterDA, and @mtelvers) - Add Macos ZFS sandbox (@mtelvers ocurrent/obuilder#164, reviewed by @tmcgilchrist) - Support XFS store (@mtelvers ocurrent/obuilder#170, reviewed by @tmcgilchrist) - Search for bash rather than assume it lies in /bin (@dustanddreams ocurrent/obuilder#159, reviewed by @tmcgilchrist) - Prune builds one at a time up to the limit (@mtelvers ocurrent/obuilder#157) - Specify upper bound on number of items in the store (@mtelvers ocurrent/obuilder#158, reviewed by @MisterDA) - Fix case where BTRFS is not fully allocated (@mtelvers ocurrent/obuilder#162) - Avoid pruning parent cache objects (@mtelvers ocurrent/obuilder#176, reviewed by @tmcgilchrist)
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.
When a new obuilder job is accepted by ocurrent/ocluster the
buildfunction in obuilder_build.ml is called. This checks that there is enough free disk space possibly spawning an asynchronous threaddo_pruneto prune builds before runningBuilder.build.do_pruneinvokesBuilder.prunewhich callsStore.prunefromdb_store.ml. The prune function queries the database to build a list of items ordered by the least recently used and begins deleting them. The delete operation takes several minutes or longer, however the list of items was evaluated at the start. It is possible that the build job which was started in parallel withdo_pruneor a subsequent job will use one of the cache steps which is in the list to be pruned.The workaround proposed here is not perfect. It minimises the chance that this will happen by checking the last used time for each item as it is deleted. We will now have one SQL query per item deleted which is less efficient.
The logging has also been updated to show the start and end of the prune operation: