Allow to search for builds and buildsets using substrings of job_name,
project, branch, and pipeline.
This is the user-facing part of 908420.
Change-Id: If3c8b870a4f9feb8c50a19cda8115aef048f75b9
This switches the config error page to use the new server-side
filtering and pagination support. Note that we still fetch the
full set of config errors in order to display the bell icon. That
will be updated in a future change.
Change-Id: I08a554c2a8151e24e5423608ef016f3273b3d663
This adds a theme selection in the preferences in the
config modal and adds a new dark theme.
Removes the line.png image and instead uses CSS
linear-gradient that is available in all browsers
since around 2018, also fixes the 15 pixels spacing
issue that is there today.
You can select between three different themes.
Auto will use your system preference to choose either the
light or dark theme, changes dynamically based on your
system preference.
Light is the current theme.
Dark is the theme added by this patch series.
The UX this changes is that if somebody has their system
preferences set to dark, for example in Mac OS X that is
in System Settings -> Appearance -> Dark the user will
get the Zuul web UI in dark by default and same for the
opposite.
This uses a poor man's dark mode for swagger-ui
as per the comment in [1].
[1] https://github.com/swagger-api/swagger-ui/issues/5327#issuecomment-742375520
Change-Id: I01cf32f3decdb885307a76eb79d644667bbbf9a3
User sometimes tends to copy the value from the "Change" column as a input
for filtering, which would cause a 500 error in API.
To fix this we do a input validation to indicate that the change must be
a integer for example a PR bumber. So that make it clear any other fomat
like a ref or a string with "," is not supported.
Change-Id: Ia25a60429acc48c5773c808be6a900ba9bdf608e
We now report a distinct buildset result to the database if the upstream code
review system is unable to merge a change. Previously it was reported as
MERGE_CONFLICT which makes it difficult to distinguish from merge conflicts.
Essentially, the two states we're interested in are when Zuul's merger is
unable to prepare a git checkout of the change (99% of the time, this is
a merge conflict). This is the MERGE_CONFLICT result.
The second state is when Zuul asks Gerrit/Github/etc to submit/merge a change
and the remote system is unable (or refuses) to do so. This is MERGE_FAILURE.
Change-Id: I47af242aeb19ae4b4aedde353fcc76ff82d90fbe
This is a prelude to a change which will report a distinct buildset result
to the database if the upstream code review system is unable to merge a change.
Currently it is reported as MERGER_FAILURE which makes it difficult to
distinguish from merge conflicts.
Essentially, the two states we're interested in are when Zuul's merger is
unable to prepare a git checkout of the change (99% of the time, this is
a merge conflict). This will be known as MERGE_CONFLICT now.
The second state is when Zuul asks Gerrit/Github/etc to submit/merge a change
and the remote system is unable (or refuses) to do so. In a future change,
that will be reported as MERGE_FAILURE.
To avoid confusion and use names which better reflect the situation, this change
performs the rename to MERGE_CONFLICT.
Because there are pipeline configuration options tied to the MERGER_FAILURE
status (which start with 'merge-failure') they are also renamed to 'merge-conflict'.
The old names are supported for backwards compatibility.
A SQL migration takes care of updating values in the database.
The upgrade procedure is noted as being special because of the db value updates.
If an operator doesn't follow the recommended procedure, however, the consequences
are minimal (builds which won't be easily queried in the web ui; that can be
manually corrected if desired).
A model API change is not needed since the only place where we receive this value
from ZK can be updated to accept both values.
Change-Id: I3050409ed68805c748efe7a176b9755fa281536f
Paginate results when searching for builds or buildsets. Since we do not know how
many results a query may return, display "results X-Y of many" by
default. If the total amount of results can be computed, display it.
Change-Id: If2985d6bcb194e3b074a860dab8cd5958b2577ec
Support three new filter types: checkbox, select and ternary select.
The ternary select tool is meant to support fields that can be set to
True, False, or ignored.
Use this feature to allow filtering builds by held status (i.e. show
builds that triggered a autohold only) or by voting status (i.e. show only
voting jobs).
Selects let a user choose among predefined values. Use a select to help
a user choose a result value when searching builds and buildsets.
Build page: add a thumbtack icon next to a build's status badge if that
build triggered an autohold.
Change-Id: I40b06c83ed069e0756c7f8b00430d36a36230bfa
Making the whole row table row clickable in these pages makes makes it
impossible to mark & copy any text from those rows. Users have
expressed this is an annoyance worth fixing.
This change removes the stretchable link from the whole table row and
instead allows clicking on the job name or status icon to go to
details about the job.
We have added an optional link prop to title-with-icon; note this is
used in other contexts where it does not make sense to be a link thus
the optional implementation steps. It is intentional that these links
retain their underline for discoverability.
For the mobile version (which renders the table as a nice card list), we
fall back to the "action column" solution which will be rendered nicely
as a button in the top right corner of each card. For larger screens we
hide this action column.
Note this change is a squash of several other changes to make a
consolidated review; for original details see:
I788ea37b2ca1899d90160cc52761db0a77f78508
Ifc54edf9ca348ada8e3bfd07fd135d22f9f08489
Ifc54edf9ca348ada8e3bfd07fd135d22f9f08489
Ib4c3a2159e7bad58fcc27eb3ba4b62926ce73099
Co-Authored-By: Ian Wienand <iwienand@redhat.com>
Change-Id: I276ff316b17aee932f2724f86e8f0eb1abe73c60
This updates the tables shown on the builds and buildsets pages with new
PF4 components. While the data is loading, a fetching animation is shown
and in case no results could be found the page shows an empty state.
Each table row is clickable and points to the build/buildset result page.
The table uses the same hover effect as the build list on the buildset
result page.
This change also updates the used @patternfly/react-core version to
match the current version of @patternfly/react-table [1]. Otherwise,
some of the styles in the different @patternfly/react-core versions
conflict with each other leading to wrong font-weights and wrong text
colors in labels.
[1] patternfly.org/v4/documentation/react/overview/release-notes#202010-release-notes-2020-08-17
Change-Id: I0f5e0815c53d18e8ae3570dc94594c77fecb90ce
This updates the toolbar on the builds and buildsets pages with new PF4
components. The toolbar itself doesn't handle the state of the filters,
but it provides some methods to simplify the state handling in the
parent component. This is necessary, since the filters are also used in
other parts of the page and thus must be handled in the page component
itself.
Change-Id: Iec93c1be01ec1ac096e8d3dcfa501f3488f8a3bf
Since Patternfly 4 (PF4) is a complete rewrite of the framework that
doesn't require bootstrap and comes with a new npm package, it's
possible to include both side-by-side in a project.
This change includes the necessary PF4 packages and updates the header,
navbar, drawer (shows the config errors) and global page layout with PF4
components. Once this is done, we should be able to update the other
components step by step to PF4.
Points to keep in mind for the migration phase:
1. Some Patternfly 3 CSS rules are overridden by Patternfly 4
wildcards, mostly (re)setting the padding and margin of various
elements to 0.
To fix this unwanted behaviour, there is a pf4-migration.css file
included were we can keep track on those rules and ensure that the
old padding and margin values are re-applied after Patternfly 4 is
imported.
Change-Id: I77b81fa0f97fe718207ba5a506cee300371c693b