Here is the current state of the test result page:

For comparison, in the Copr build result page, we have a link for an SRPM result page:

The task here is to:

• enhance the packit API if needed
• show the Copr build link in the details section

We already have Packit Dashboard ➡️ Copr integration. This is a tracking issue to cover the other side: being able to go from Copr web interface to Packit Dasboard (or GitHub).

Context:
https://pagure.io/copr/copr/issue/1890
https://pagure.io/copr/copr/pull-request/1970

Let's brainstorm some ideas here.

CC @xsuchy @FrostyX @praiskup

Hi
I am a GSoC aspirant. I am looking forward to applying for GSoC in fedora.

I was trying to run app.py and I got this -

I want to know is app.py is the main entry point of the whole project or some other script is the main entry point?

sudo: dnf: command not found
Makefile:5: recipe for target 'install-dependencies' failed
make: *** [install-dependencies] Error 1

• Create some tests.
• Setup the directory structure as we have in other projects.
• Add Makefile target for that.
• Make the tests in a way we can easily run them in the CI.

What to do ???

I tend to <f5> the list a few times a day - it would be very convenient for me if the list updated itself in the background

just something like github does with notifications: it tells you how many new notifications are not shown yet

• copy the pre-commit configuration from another project (like https://github.com/packit-service/packit , https://github.com/packit-service/packit-service or https://github.com/packit-service/ogr)
• try it and tweak if needed

Providing run ID in SRPM, Copr, Koji and TF API endpoints allows creating breadcrumbs for navigation through the whole pipeline of run builds or tests. Create a component that can be used at top of the result page for navigation through the pipeline. Optionally provide link to the pipeline result from #130

Dashboard can be moody - The requests fail with Connection error sometimes:

127.0.0.1 - - [27/Jan/2020 16:39:33] "GET /projects/?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:34] "GET /projects/?__debugger__=yes&cmd=resource&f=ubuntu.ttf HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:34] "GET /projects/?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:34] "GET /projects/?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/ HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 2309, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 2295, in wsgi_app
    response = self.handle_exception(e)
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 1741, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3.7/site-packages/flask/_compat.py", line 35, in reraise
    raise value
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 2292, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 1815, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 1718, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3.7/site-packages/flask/_compat.py", line 35, in reraise
    raise value
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 1813, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python3.7/site-packages/flask/app.py", line 1799, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/dhodovsk/repos/github.com/packit-service/dashboard/main.py", line 76, in projects
    for build in all_from(f"{API_URL}/copr-builds"):
  File "/home/dhodovsk/repos/github.com/packit-service/dashboard/main.py", line 64, in all_from
    page = return_json(url_, method, **kwargs)
  File "/home/dhodovsk/repos/github.com/packit-service/dashboard/main.py", line 37, in return_json
    response = requests.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3.7/site-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3.7/site-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3.7/site-packages/requests/adapters.py", line 498, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/?__debugger__=yes&cmd=resource&f=style.css HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/?__debugger__=yes&cmd=resource&f=jquery.js HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/?__debugger__=yes&cmd=resource&f=ubuntu.ttf HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -
127.0.0.1 - - [27/Jan/2020 16:39:56] "GET /projects/?__debugger__=yes&cmd=resource&f=console.png HTTP/1.1" 200 -

Would it be hard to use the stage icon in the stage deployment?

It's not so important but would be nice to match the behaviour on Github/GitLab where we use different avatars.

Logo on page links to the page itself. Clicking on it opens dashboard in new tab.

How to reproduce:

1. Open dashboard
2. Click on packit logo
3. Dashboard gets opened in new tab

Expected outcome:

1. Current page is switched to the homepage of dashboard

• Create a nice view of a single result. (We already have a table/list of them at https://dashboard.stg.packit.dev/jobs).
• Basically, it should be a nice-looking variant of the old result page packit-service is providing.

Here is a list of information I would like to see for all job types:

• Project name and link to the upstream
• Information about upstream trigger (PR, branch, release) and link to it.
• Human readable datetime.

In the case of SRPM, add:

• Logs
• (old version: https://stg.packit.dev/srpm-build/3070/logs)

In the case of Copr build, add:

• SRPM logs / link to the SRPM view
• Link to download SRPM file
• Link to Copr project web UI (e.g. https://copr.fedorainfracloud.org/coprs/packit/packit-hello-world-231-stg/build/1954610/)
• Link to Copr logs (e.g. https://copr-be.cloud.fedoraproject.org/results/packit/packit-hello-world-231-stg/fedora-33-x86_64/01954610-hello/builder-live.log.gz)
• Install instructions.
• (old version: https://stg.packit.dev/copr-build/8830)

In the case of Koji build, add:

• SRPM logs / link to the SRPM view
• Link to Koji web UI
• Link to the logs page
• (old version: https://prod.packit.dev/koji-build/59)

In the case of Testing Farm result, add:

• Link to the Copr Build view
• Some status, basic result description
• Link to the TF dashboard/result page
• No alternative in the service.

I've described all the pages so we have a bigger picture and see if something can be shared/connected.

In the list of jobs, we provide URL to our own result pages in all cases except COPR

• Switch URL to our result page (or add new column Results)

I spent the last day looking a lot into the Pipelines view and it would be really nice to get a PR/MR description when hovering on the PR/MR link.

Something like this:

Is it anyhow useful to show install instructions for builds that failed?

Example: https://dashboard.packit.dev/results/copr-builds/110905

Without timestamps it is hard to tell when the jobs run, which can be handy.

https://dashboard.packit.dev/jobs

Our README is pretty basic, can we get some more text in there?

Most of the project on the projects page is irrelevant because they don't handle any pr/issue/branch/release.

What about skipping those projects (they don't bring any value)? Or adding some option to opt-in/opt-out from listing them.

I've been a bit confused about the PR icon in the project list.

What about something like this?

And we can maybe use fa-tag/fa-tags for release.

Or maybe something like upgrade:

Part of #119.

We need to provide this information via Packit's API.

• Add a new column to the SRPM Builds tab here. (Or find a better place where we can put this info.)

Requires: packit/packit-service#958

Now, I can't search all the projects on one git forge -- e.g. all the GitHub projects.

It would be nice to allow * or any regex?

A related one, what about treating empty field(s) as all(=*)?

So the task here is to:

• allow a search of all projects on the git forge (only the first field is set) - done in #122
• allow a search of all project for a namespace (only the forge and namespace is set) (EDIT by @lbarcziova: this already works with empty project field and * as well)

We got a report from @msehnout that they cannot load https://dashboard.packit.dev/projects/github.com/osbuild/osbuild

Easily reproducible, the error is:

Unable to connect
There was an error retrieving data.

Console seems to suggest that:

Access to fetch at 'https://prod.packit.dev/api/projects/github.com/osbuild/osbuild' from origin 'https://dashboard.packit.dev' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Do we just need to set some CORS-related header to make browsers happy?

Provide a view for the propose-downstream job using packit/packit-service#1292

Users want to see:

• Upstream event that was used to trigger the job.
• State the job is in.
• Logs.
• Links to the downstream PRs.

• the forge icon at /projects/... is hardcoded to github right now, replace it with the correct one
• Jobs view should also display git forge icon in every row

I'd love to see a datetime of the SRPM build so that I know the timespan I am looking at.

After helping someone with the TF today I feel like It's now not clear where a user can find more details about the TF result.

My concerns:

• People don't need to know doest the Testing-Farm mean.
• The term result is used as a link to the Copr build, not for the actual Test results.
• The field names are not consistent (with or without URL).

AC:

• Remove the "Testing Farm URL" field, and place the link on the Status text, that is "passed" or "failed" will be also a link to the testing farm page.
• Instead of "Copr build: Results" say: "Copr build: Details"

Take the acceptance criteria as a suggestion.

At this moment the build logs are not wrapped to browser window size and that makes it quite hard to read essential information from lines that are longer than the window.

https://dashboard.packit.dev/results/srpm-builds/28981

This css hack seems to achieve the desired wrapping:

code {
    white-space: pre-wrap;
}

This behavior would also match what a normal user terminal would see, as terminals do not usually hide the long lines and do wrap them instead.

The jobs page in Dashboard should show some useful charts.

TODO for @csomh to figure out what these should be.

Route: /results/testing-farm/<id>

We show <a> link for testing farm even though we do not have any link yet.

Each git forge has its own url scheme for issues, pull/merge requests and braches. Since we now provide the forge name and other repo details in the API, dashboard should make links according to the respective forge's url scheme.

• /project.../issues
• /project.../releases
• the trigger column in jobs view should link to pull request or branch
• copr link should be moved over to the build id column

The message for successful Copr builds looks like this:

Congratulations! One of the builds has completed. :champagne:

You can install the built RPMs by following these steps:

* `sudo yum install -y dnf-plugins-core` on RHEL 8
* `sudo dnf install -y dnf-plugins-core` on Fedora
* `dnf copr enable packit/nmstate-nmstate-852`
* And now you can install the packages.

Please note that the RPMs should be used only in a testing environment.

from nmstate/nmstate#852 (comment)

This could be more specific:

• It mentions Fedora but Fedora is not part of the configured chroots
• It mentions only RHEL 8 but it should also work for CentOS and probably also RHEL/CentOS 7 with the correct command
• It does not mention how to install/update the packages but the information should also be available to packit.

Favicons don't work for the dashboard. They are caught by the React and 404 gets returned.

Can be reproduced:

• deployment of production and stage
• locally via container

Cannot be reproduced:

• locally via yarn

I'm pretty sure Adam Saleh story's are fascinating but regardless his storydrafts are not packaged in Fedora thus there needs to be means to filter such stuff out. That said you will pretty fast exhaust all infra's resources if everything and everyone is allowed to use packit for anything so I recommend that packit is limited only to official teams/maintainers and their official maintained packages in the distribution. ( If packit takes off for real then you are talking about what 14k+ components that will be using it )

The Jobs tab of the service dashboard does not allow searching the list by any criteria. The list can be only sorted and not even by any column, only a subset of them.

One has to search on the page using the browser functionality, which is fine for new jobs, but not very convenient for jobs triggered e.g. 1 or 2 days ago. Due to pagination, one has to click multiple times to "Load More" jobs, until they find the specific one.

It would be great if the Jobs tab had a search functionality allowing to quickly find a specific job (or a set of jobs) based on various criteria (e.g. project name, PR number, etc...).

There is no content being displayed on the dashboard other than "Dashboard Page Title" which is kinda useless...

The project page in Dashboard should show some useful charts.

TODO for @csomh to figure out what these should be.

...and describe how to run dashboard locally and in a container

Create a result page for single pipeline (ideally with merged runs). Try to use as much as possible from the result components used so far.

Edit:

• make sure that all builds and tests are included in the view

How to reproduce:

• lower width of view than full HD; by slowly narrowing the view it is possible to see the shrinking in progress

Doesn't happen with regular icons (can be seen on SRPM status on the screenshot), suspected bug on upstream.

Example:

• get inspired by the other projects in the packit-service organisation
• look at the docs (https://github.com/packit-service/research/tree/master/zuul)
• create necessary files (like we have in other repos)

What will be run in the pipelines:

• have pre-commit as a first job (#12 ) (pre-commit run --all)
• have some tests as a second job (#21)

https://dashboard.packit.dev/jobs I can see copr builds, koji builds and test runs

Can we get srpm builds as well? With a link to PR and logs, that would be awesome, thanks!

If the dashboard.packit.dev site goes down you cant check the api health status which is like having to walking into a burning building to check if the water flow is OK 😄

Place a status page outside the project's infrastructure, which checks for all the relevant stuff and link to that page instead.
Like for example [1][2].

1. https://www.githubstatus.com/
2. https://status.fedoraproject.org/

Our current way to compile/transpile Javascript is a custom webpack config, which we needed because React's default preconfigured Create React App toolchain (which itself is based on webpack) couldn't inject environment variables in JavaScript at build time.

I realized that it can do that now, but only with env vars starting with REACT_APP_.

React generally recommends writing your own webpack config if using it with something like flask, but we don't need any advanced webpack features so I think its time to retire our config.

On the flip side, switching to Create React App would give us:

• Proper Code splitting and our final prod js bundle size is halved. (tested the half thing by compiling dashboard with CRA, but I think it can be reduced even more if we make it aware of routes later someday)
• No need to maintain or rely on webpack.config.js
• Warnings about bad JS/React practices
• Better debugging (and better error messages during dev)

All this can be done by writing your own config, but its too complicated and I'm not a fan of the JS/npm ecosystem.

BTW, if we do this, we'll have to provide another env variable in openshift, something like REACT_APP_DEPLOYMENT because it needs to start with that.

All of the code will remain the same, but there might be some changes to the folder structure. I can do it next weekend if everyone is okay with it.