While it's useful to have a clickable link to the fixing pull request
on the runbot error list, we cannot display the entire url as it takes
too much space. So a static text `View PR` is used.
As this static text is of limited use, this commit adds a new widget
that displays a shortened URL for the github pull request only showing
the repo and the PR number.
- Add dropdown-toggle to the github tool button so that it doesn't
appear as if a button should be following it.
- Add default btn classes to category icons, the button would otherwise
be displayed as just an icon.
- Add a gap between the two toolbars.
- Add d-empty-none in case we have no category to display to remove the
useless gap.
When the reference build for some build is not done yet a message is
logged with a link to the referenced build, however due to a typo in the
message the markdown was badly formatted.
`target="new"` had the very confusing behavior of updating the same tab
within the same browser context (tab).
The commit replaces all `target="new"` occurences with `target="_blank"`
within the runbot templates.
See: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#target
Revert "[FIX] higher sleep values"
This reverts commit c562dac84d.
This was done before upgrading the postgresql serevr hardware. we should
be able to have faster updates now.
For a strange reason, the runbot got stuck while updating a ci status.
The reason why it occurs know just after the upgrade is unknown, but
adding a timeout may help to mitigate this issue.
Since https://github.com/odoo/odoo/pull/154710 form views can use
<chatter/> directly to include the chatter, not doing so completely
breaks the dom generated by the form view.
Adds a very limited ability to try and look for false positive /
non-determinstic staging errors. It tries to err on the side of
limiting false false positives, so it's likely to miss many.
Currently has no automation / reporting, just sets a flag on the
stagings which are strongly believed to have failed due to false
positives.
While at it, add link between a "root" staging and its splits. It's
necessary to clear the "false positive" flag, and surfacing it in the
UI could be useful one day.
Fixes#660
Rather than add individual tunnel methods to conftest, just allows
specifying a tunnel script and have that do whatever.
Protocol is uncomplicated: workers run the `$tunnel` with an arbitrary
port, script should create a tunnel to `localhost:$port`, print the
ingress of the tunnel to `STDOUT` with a terminating newline then
close `STDOUT`, and wait for `SIGINT` or `SIGTERM`, doing whatever
cleanup they need when receiving either of those.
`ngrok` and `localtunnel` adapter scripts are provided out of the box,
though the ngrok one doesn't *really* work when using xdist without a
pre-spawned ngrok worker. Then again using xdist against github actual
is suicidal (because concurrency limits + rate limits) so likely
irrelevant.
Fixes#729
Requires parsing the commit messages as github plain doesn't collate
the info from there, but also the descriptions: apparently github only
adds those to the references if the PR targets the default
branch. That's not a limitation we want.
Meaning at the end of the day, the only thing we're calling graphql
for is explicit manual linking, which can't be tested without
extending the github API (and then would only be testable on DC), and
which I'm not sure anyone bothers with...
Limitations
-----------
- Links are retrieved on staging (so if one is added later it won't be
taken in account).
- Only repository-local links are handled, not cross-repository.
Fixes#777
In that case, ignore the reopen, close the PR, and tell the idiot to
fuck off.
Also the case where a PR is reopened while its batch is staged was
already handled, but probably not tested: it was implicit in
forcefully updating the HEAD of the PR, which triggers an unstage
since c8a06601a7.
Now that scenario is tested, which should lower the odds of breaking
it in the future.
Fixes#965
Identifying build errors by fingerprint is not enough.
Most of the times we want to link build errors based on some criteria.
With this commit, a build error can be qualified by using regular
expressions that will extract informations.
Those informations will be stored in a jsondict field. That way, we can
find simmilar build errors when they share some qualifiers.
To extract information, the regular expression must use named group
patterns.
e.g:
`^Tour (?P<tour_name>\w+) failed at step (?P<tour_step>.+)`
The above regular expression should extract the tour name and tour step
from a build error and store them like:
`{ "tour_name": "article_portal_tour", "tour_step": "clik on 'Help'" }`
The field can be queried to find similar errors. Also, a button is added
on the Build Error Form to search for errors that share the same
qualifiers.
The `to_pr` helper was added a *while* ago to replace the pretty
verbose process of looking a PR with the right number in the right
repository after a `make_pr`. However while I did some ad-hoc
replacement of existing `search` calls as I had to work with existing
tests I never did a full search and replace to try and excise searches
from the test suite.
This is now done. I've undoubtedly missed a few, but a hundred-odd
lines of codes have been simplified.
BS5 namespaced the data-attributes it uses to trigger JS
behaviours. So for dropdowns `@data-toggle` doesn't do anything
anymore, one has to use `@data-bs-toggle`. Missed that while testing
the migrations.
Also seems like `@aria-expanded` was misapplied when I added the
dropdowns:
> When a menu is displayed, the button object that toggles the
> visibility of that menu has aria-expanded="true" set. When the menu
> is hidden, aria-expanded can be omitted. If specified when the menu
> is hidden, it should be set as aria-expanded="false".
Since the dropdowns are hidden by default, the button should be
`@aria-expanded="false"`.
