Syncing from upstream odoo/runbot (19.0-handle-large-logs-moc)#1089
Open
bt-admin wants to merge 64 commits into
Open
Syncing from upstream odoo/runbot (19.0-handle-large-logs-moc)#1089bt-admin wants to merge 64 commits into
bt-admin wants to merge 64 commits into
Conversation
When using automatic rebase, in some cases the created build could be linked to an existing one. This is becase since threehash we don't use the commit.id, and thus ignore the rebase_on in the fingerprint This fixes the issue by adding the rebase_on treehash in the fingerprint In an ideal world we would be able to predict the threehash if the rebase was real.
Can be set on staging bundle to increase priority First builds of forwarports will have a lower priority.
No need to set @Odoo-Module tag at top of .js files as it is already the default.
Use double-quote by default ; string template instead of concatenation.
Escaping non-special characters in strings, template literals, and regular expressions doesn’t have any effect.
when using dev=xml on runbot the page loading is verry slow (~20 seconds) This is mainly due to an intensive usage of tcalls to generate all small elements in the page. Whith dev=xml, the template is read and recompiled for each call. Using the transaction cache instaed will highy reduce the page loading time (from 20 second to 0.8 second) while allowing to reload the templates at each page loading.
This commit introduce a possibility to conditionnaly load some lighter config at a early stage of a task.
If no trigger is found, a crash would happen when trying to call 'id' on it (when trying to pass its value to the JS script).
This branches adds - a hook for mergebot to request the start of all builds in full mode - fields on project to define ways to enable light config by default. - fixes Action visibility for non advanced users
This commit updates the Chrome version used in the default docker image.
BS button "default" variant styling coherence depending on the states (regular/hover/active) and fixing the missing border color on active state. Also fix the search field's "github PR" button styling.
On an error, tests tags are joined by a comma and displayed in a single line. This makes it hard to read and edit when there are many tags, especially if they have parameters. This commit changes the separator to a newline, making it easier to read and edit the tags. In the future, it may also make the parsing more robust as we can easily split on \n, but the validation is still a good idea. This commit also adds a check on the format of the test tags to prevent saving invalid tag and hopefully complelty preventing saving tags that would break all builds. While on it, fixing the impacted error domain for parametric tags since right now they would match all errors ignoring the parameters making this feature pretty much unusable.
When reusing a similar build as a quick result, first look for a build with global_result == 'ok'. Fall back to the existing logic (any done build not skipped/killed) only if no successful build is found. Without this, a previously failed build could be used to shortcut subsequent similar builds, propagating the failure without letting them run.
When a breaking PR is assigned to multiple build errors, a stat button now appears showing the count of duplicates. Clicking it opens a list of errors sharing the same breaking PR, allowing the user to review and potentially merge them.
The coverage was unusable because the test time was to long, and nothing was made to make it run in parllel. This new version allow to configure the coverage via config data to be able to enable it on a parallel testing or single app test as an example , and a custom step will be needed to recover all result, combine them and generate a report. Moreover, the --branch options adds and overhead of 20% but is needed to but may not be 100% necessary (better have a coverage with no branch than no coverage at all), so it is now optional. It is also possible to enable the test context to know what test was reached what branch, experimental but could be useful if the overhead is not to high.
In some cases, two batch can be creted for the same forwardport. A first one one the branch creation A second on the pr creation It is mostly the case when github or mergebot as an issue and delays the pr creation, in this case 40 minutes after the branch. This pr fixes the issue by relaxing the condition allowing to build all for the two first batches of a forwardport.
When a build runs steps using Docker containers, the time spent in those containers was not tracked. With this commit, a `docker_time` field is added to accumulate the time spent in Docker containers across all steps of a build.
Uses the BS modal styling but adapted to the `<dialog>` element instead of BS javascript. Note: preferences in itself aren't modified as this is not this commit's goal. Note: includes a very adhoc and basic polyfill to support command and commandfor attributes on "older" browser (i.e. tested Safari 18 < 26 and Firefox ESR 140).
The `keep_running` boolean field on BuildResult was a simple flag to prevent builds from being automatically killed. The drawback is that sometimes those builds are forgotten and stays alive forever. This commit replaces it with a `gc_running_date` field. Now, if a date is set, the build can only be killed by _gc_running after that date.
Fetch using ssh are slow those days, adding support for fetch using https with token
When runbot fetch a commit, it will try to fetch the complete repo first The main reason is that the other commit, branches, bob, .... could be needed later, so making one call to github looks more efficient. With the increasing number of dev branches and workers, the fetch becomes a problem and can be slow, mainly when no fetch was done for a while, and the repo has a tons of pending updates. This pr tries another approch to only fetch the single requested commit, which could be faster.
When fetching from GitHub, the git process sometimes hangs for a long time regardless of whether https or ssh is used. Investigation showed that the last child process of the git command is always the one hanging. Killing that subprocess allows git to retry the operation without data loss. This commit monitors the git process and kills its hanging child process on timeout.
Since #1418 when a fetch is too long it can be killed to prevent staying on a slow fetch This works well with the _update_fetch_cmd since it will retry multiple times, but not with the commit._fetch that won't retry at all. If a commit takes more than 30 second to fetch the build will fail in this case. Adding a retry inside the _git in case of killed fetch and increase the timeout.
Since we don't call update anymore, it is possible that the repo is not initialized yet.
When building Dockerfiles, it happens that even if nothing changed in the Dockerfile itself, the image should be rebuilt. e.g.: depending on when an image is built, an `apt-get install foobartool` may give a newer version of `foobartool`.
Since dynamic config were introduced, a Falsy value was given as cpu limit bypassing the step limit and max limit in run_odoo_odoo This is fixed by setting the step limit fist in run_odoo_odoo The limit is also set on the docker but improprely used to kill the build manually. To avoid having to compute it twice the same way, the limit is now stored on the build and the same value is used to gc the build. We still have a fallback on the step limit, so both values needs to be Falsy in order to disable the limit, and provide a default waiting for the build.cpu_limit to be set on all builds.
Since the runbot executes Docker containers non-blockingly, there is no direct way to capture the main command's exit status. With this commit the exit status code of the main command is written to a file. It also adds a new boolean field 'check_exit_status' on ConfigStep that enables checking the exit status. When enabled, the step reads the exit status from the dedicated file and sets the build result to 'ko' if the exit code is non-zero. This allows config steps to properly detect and handle command failures that may not produce error logs but still indicate a failed execution.
Some tests can fail randomly because they reach memory limit. Setting a slightly lower memory limit during the nightly will help to detect such tests and provide an easier way to fix them early.
When parsing build errors, it may happen that the error appears in a version lower or higher than the current test tags bounds. With this commit, when a build error log is manually parsed (via the web interface or the server action), the min and max version bounds of the test tags are updated accordingly to include the new builds versions.
d-fence
force-pushed
the
19.0-handle-large-logs-moc
branch
from
2818086 to
df2aa55
Compare
d-fence
force-pushed
the
19.0-handle-large-logs-moc
branch
from
df2aa55 to
cfe589b
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
5 participants
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.
bt_gitbot