Syncing from upstream odoo/runbot (19.0-build-errors-frontend-app)#1086
Open
bt-admin wants to merge 38 commits into
Open
Syncing from upstream odoo/runbot (19.0-build-errors-frontend-app)#1086bt-admin wants to merge 38 commits into
bt-admin wants to merge 38 commits into
Conversation
This commit adds the possibility to filter modules based on their dependencies and dependants in the build configuration. This allows to easily trigger tests on modules that are impacted by changes, even if they are not directly modified. To make it work the modules listing is now done only in the git repository, without exporting sources, this should help to easily to have faster builds when the only task is to create builds based on modified modules. This should also and mostly help to test a dynamic config without running it.
This will be a first step to test the message queue before switching state recomputation inside it.
When a build is already ko, it should not be switched to killed This fix replicates the logic of the requested action processing.
Remove some not so needed elements, add links on all file looking paths
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.
With this commit, the authors involved in a bundle are computed. Authors are found based on github logins first, then from the ngram extracted from the bundle name. The teams are infered from the authors found. Finally an `Owning team` is automatically choosen (the first team of the teams) or can be manually set.
This commit improves the readability and usability of the freeze page : - use a more structured grouped table paradigm to provide more cohesive alignment and readability. - add collapse/expand teams' PRs. - add per team counters - add collapse/expand all - add tags/"done" filtering To support those changes, the TableGroup and TableFilter js components have been added, providing a generic addition on top of Bootstrap's classes.
pparidans
force-pushed
the
19.0-build-errors-frontend-app
branch
from
29ddc6a to
498c2f4
Compare
pparidans
force-pushed
the
19.0-build-errors-frontend-app
branch
from
498c2f4 to
a8b02c0
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