Add Copr Builds to the dashboard.

[IceWreck]

I added recent copr builds to the dashboard. Right now it only shows the recent ones because fetching all of them triggers issue #5
I plan to add a button to load older builds as well so that it doesn't fetch too much data in one go.

The table can be sorted and filtered by project name, build status, etc thanks to datatables. (no additional dependencies, patternfly already has it as dependency)

[jpopelka]

Looks great to me.

@sakalosj or @dhodovsk do you want to take another look?

[sakalosj]

looks nice 👍

[lachmanfrantisek]

Nice improvement, thanks!

• The link to the original PR would be nice. (We can improve that later.)
• Some notes regarding the GSOC task since @csomh is now off for some days:
  • It's not time to work on the main task yet...;)
    • Now, you have time to get familiar with the project, play with the code and write a proposal. (In this period, everyone can contribute, but on the main task, we can mentor only one student.)
    • During the task, we would like to spend some time on the design before real coding.
  • Please, pick some existing issue (or create a new one) and write in advance that you want to work on it so we can easily manage all the contributions. (So multiple people don't work on the same thing.)

Thanks, the table looks very clean!

[IceWreck]

@lachmanfrantisek
Like you suggested, I disabled the filter on the build target OS column.

[IceWreck]

@lachmanfrantisek I implemented the Pull Request link button which shows up only when the build id is provided. However, in some cases api/copr-builds/{id} returns nothing even when api/copr-builds/ provides the exact same id.

One solution would be to show the View PR button on builds that do return an id and then in the rare case that the api returns nothing, just display an error message. But the proper way would be the fix the root cause of the issue, in the API code.

So should I continue with the former solution or just leave it for now?

[lachmanfrantisek]

One solution would be to show the View PR button on builds that do return an id and then in the rare case that the api returns nothing, just display an error message. But the proper way would be the fix the root cause of the issue, in the API code.

As I wrote in the issue, these are probably the old data from early dates of the service.

• Should be completely fixed after we fully switch to PostgreSQL.
• Should not occur for new jobs.

So should I continue with the former solution or just leave it for now?

Let's leave it as is and prepare the needed/wanted data in the API first.

[lachmanfrantisek]

Please, rebase, so we have a nice git-history.

(We don't have it covered by the CI check yet as we do in other projects.)

[IceWreck]

@lachmanfrantisek Rebased.

[lachmanfrantisek]

@lachmanfrantisek Rebased.

Thanks, merging.