ocaml-ci
ocaml-ci copied to clipboard
ocurrent
Feedback relating to the design and UX of ocaml-ci
As we roll out the new designs, this is an overarching issue to collect feedback from the users of ocaml-ci. Please add a comment describing your feedback - please be specific about the problem (or benefit) you are experiencing and make a suggestion for an improvement. We will triage these and work on them as appropriate.
Logs are difficult to read - can we have an option to have a light background? https://github.com/ocurrent/ocaml-ci/pull/527#issuecomment-1256326701
I really like the new CI look, but I was wondering if we could try to to optimise a bit more for using the screen efficiently - the font for logs is quite large for instance (by @samoht)
From @tmcgilchrist via slack:
Feedback via other channels:
- Sorting / filtering on this page would be nice https://ci.ocamllabs.io/github/ocaml-gospel/cameleer/commit/11048c
- Show failure / error directly? Scroll to the end?
- Analysis displaying results better (nice to have) https://ci.ocamllabs.io/github/ocaml-gospel/cameleer/commit/11048c/variant/(analysis)#L777-777
The log display is too narrow (for GitHub projects). It wastes most of the screen with borders, forcing you to scroll horizontally to read longer lines (it's fine for GitLab projects, though, which use the whole width of the window).
From @emillon via slack:
nice! you might want to tweak the CSS though, the contrast is very hard in some cases
(Context - colours in logs)
The piece of logs in particular was:
According to contrastchecker this is contrast 1.88:1 whereas 4.5:1 is recommended for normal text.
ANSI colours for code in the logs is still light for some text, despite the light background (for example see the opam install part of any build).
ANSI colours for code in the logs is still light for some text, despite the light background (for example see the
opam installpart of any build).
Anyone familiar with ansi able to help out with this? I don't understand how it's selecting colours - the logs in opam-health-check do not get these decorations and I don't know why they do here or how we can change them. We are simply doing
https://github.com/ocurrent/ocaml-ci/blob/4f76419ca5c5cfad2fab36bfd737aa3f65b8c8e9/web-ui/view/github.ml#L491
https://github.com/ocurrent/ocaml-ci/blob/4f76419ca5c5cfad2fab36bfd737aa3f65b8c8e9/web-ui/view/github.ml#L534
Ansi' css is loaded here for ocaml-ci-local:
https://github.com/ocurrent/ocurrent/blob/a5594bf11f4dbe43040b8736ee3091ae90d498ac/lib_web/current_web.ml#L53
and there for the web-ui:
the css definition is there: https://github.com/ocurrent/ansi/blob/master/lib/style.ml
IMO what we could do is defining color schemes in ANSI, with the appropriate set of ANSI sequences to CSS color definitions maps, including the default background color that's currently not part of the ansi lib. We could include Tango, Solarized, Gruvbox?
Presumably the current color palette of ansi is thought for a dark background.
Now I'm going to check whether ansi just supports the ANSI escape codes, or 256 colors and truecolor as well :art:.
Presumably the current color palette of ansi is thought for a dark background.
I'm pretty sure that this is used in checks.ocamllabs.io and was also used in ocaml-ci prior to these designs ... and those were all light backgrounds. In fact in checks.ocamllabs.io the example of the opam install section that Ben points to appears as black text.
The mobile styling looks great on iOS.
I think it could be further improved by reformatting the variant names further (make them types in the code rather than string) and maybe reformat the details below the major heading (the central justification looks wrong). Also a bit more contrast on the dark mode text below the main heading.
The list of repositories is not very dense - it would be nice to pack more information in these instead of having to scroll. Maybe use multiple columns or removing padding?
The ANSI color situation should be fixed by now. It's also easier to switch to another colorscheme, so we can revisit that if needed.
User @art-w reported:
While you are at it, can you wrap the long log lines in a
<marquee>tag? Scrolling horizontally is really inconvenient.
<marquee> itself is deprecated and shouldn't be used, but there's a case for wrapping lines.
Hi! suggestion from Slack:
minor suggestion regarding wording: at the moment both active jobs and completed jobs say "Ran for %dm%ds". How about using "Running for..." for active jobs? (assuming that's correct english)
Direct links to projects return 404 https://ci.ocamllabs.io/github/mirage/ocaml-github/ returns 404 while https://ci.ocamllabs.io/github/mirage/ocaml-github (without the trailing slash) is ok.
CC @maiste
Rendering the index page (with both Safari and Chrome on macOS) shows un-evenly spaced lists and sometimes tears individual organisations.
Direct links to projects return 404 https://ci.ocamllabs.io/github/mirage/ocaml-github/ returns 404 while https://ci.ocamllabs.io/github/mirage/ocaml-github (without the trailing slash) is ok.
CC @maiste
This is a problem associated with Dream. This problem is present in other websites with this issue related to it in ocaml.org: https://github.com/ocaml/ocaml.org/issues/820. Maybe a common fix should be found.
It's so pretty! <3
One tiny thing in nightmode, I have trouble reading the highlighted line:
The logs highlighting only extends to the edge of the initially visible window; once you scroll horizontally the highlighting ends.
The bug is purely visual, if you click on a log-line outside of this area the text will still be highlighted.
This is a difficult problem to solve due to the current structure of the HTML/CSS, which relies on text-overflow to allow logs to extend past the edge of the window.
It would be nice to have the page scroll automatically, to stick to the bottom if it's already there and there are still logs being pushed. If someone manages to do that for the ocaml-ci UI, could they also port the feature to ocurrent?
It would be nice for the page title to be more relevant to what page you are on, instead of always being 'OCaml-CI'. I often have multiple pages open for comparison and it can be a pain remembering which is which (for example on the logs page having to scroll to the top if I forget which variant I'm on).
I have suggestions for some pages:
- Organisations page, keep as 'OCaml-CI'.
- Repos page, use the name of the organisation.
- Refs page, use the full name of the repo e.g. 'ocurrent/ocaml-ci', as one may be comparing forks of the same repo.
Beyond this, names get a little long and unwieldy (PR title for steps page? variant name for logs page?) so it'd be useful to get other's opinions.
Would it be possible to be able to filter which jobs to run for a specific project? For example I have some code that works fine on 64-bit platforms but which would require an undesirable push to int64 to run smoothly on 32-bit platforms.
Filtering out the arm32 and x86_32 jobs would solve this.
@benmandrew
Beyond this, names get a little long and unwieldy (PR title for steps page? variant name for logs page?) so it'd be useful to get other's opinions.
I agree with the first suggestion. For the building and step page, I would suggest using the short commit with the repo name.
@ElectreAAS
Would it be possible to be able to filter which jobs to run for a specific project? For example, I have some code that works fine on 64-bit platforms but which would require an undesirable push to
int64to run smoothly on 32-bit platforms. Filtering out thearm32andx86_32jobs would solve this.
If this is about the job to run, this is something that should live in the opam files. You can't deactivate 32 bits arch by using a combination of available and arch in this file (more details here.
If this is about the job to run, this is something that should live in the opam files. You can't deactivate 32 bits arch by using a combination of available and arch in this file (more details here.
Oh wow didn't know about this, thanks!
On firefox (but not chrome), copying lines from the build log adds an additional \n in between every line:
FROM ocaml/opam@sha256:e5764d4b72321ec73401faf7c33eb2e60256850d8421a70033936aeb52962fe5
# alpine-3.16-5.0_opam-2.1
USER 1000:1000
etc
edit: Only in the build logs, not the "Steps to reproduce" or its copy button
On firefox (but not chrome), copying lines from the build log adds an additional
\nin between every line:FROM ocaml/opam@sha256:e5764d4b72321ec73401faf7c33eb2e60256850d8421a70033936aeb52962fe5 # alpine-3.16-5.0_opam-2.1 USER 1000:1000 etcedit: Only in the build logs, not the "Steps to reproduce" or its copy button
It seems to be related to the fact that Firefox considers that each div is different so when you copy text from different diff it auto insert an empty line break between tags.....
Thanks for the improvements so far. But I still find the font quite big (at least on my laptop screen), so I'm using an 80% zoom to see more info at once.
Thanks for the improvements so far. But I still find the font quite big (at least on my laptop screen), so I'm using an 80% zoom to see more info at once.
@samoht could you provide us with a screenshot so we could see how it looks like on your screen and see how we could solve the problem? :smile:
Using Safari, if you watch the build log, extra line breaks appear which are not present when you go back and review the log later. For example, this is how the log appeared as I watched it.
Revisiting it after it had finished showed:
