build-canaries / nevergreen

:baby_chick: A build monitor with attitude
https://nevergreen.io
Eclipse Public License 1.0
210 stars 38 forks source link

lastBuildLabel is not shown on projects with status Unknown #269

Closed galan closed 5 years ago

galan commented 5 years ago

Bug report

How are you running? docker run -p 5000:5000 buildcanariesteam/nevergreen:3.0.0

Nevergreen version? v3.0.0+1393.ff97f79 Nintendo Red

What are you running on? Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/71.0.3578.98 Chrome/71.0.3578.98 Safari/537.36

Which CI server(s) are you monitoring? Self-build ccmenu server (might be open source soon)

Expected behaviour? The content of the field lastBuildLabel is shown beside the project when the status is unknown. It should be the same behaviour as with the other states. Otherwise I end up with multiple unknown jobs, without knowing the source (since the label is missing all look the same). Also the lastupdate is missing, might be of interesst too.

Actual behaviour? The label is not shown, leading to multiple projects shown in nevergreen, but all look the same.

Steps to reproduce?

  1. Request a ccmenu resource with multiple projects with the same name, state unknown and different labels.
  2. Try to distinguish the projects.

Side note, I'm monitoring gitlab, where the label contains the actual git ref. This is used, since gitlab just provides the list of pipelines executed, so I group the projects by name and ref, since each ref can have a different state in the gitlab pipelines.

GentlemanHal commented 5 years ago

Hi @galan, thanks for raising this issue, this is an interesting one!

The reason we only show the build label on sick projects is a quirk of all the CI servers I've used. They only update the lastBuildLabel in the CCTray XML feed after the build has finished building. This means if we displayed the last build label on building projects it would always be incorrect.

Having said that, for projects with an unknown prognosis it's probably OK to show the last build label as well. So this is a change we could make.

Your comment about project name is more interesting and the bigger issue here.

Since the CCTray XML format does not provide any unique identifiers for projects we have to use the project name. This means it's not currently possible to display multiple projects with the exact same name. We store projects in the redux store by name so if multiple projects with the same name are returned by the server they get overwritten, and this is very unlikely to change (certainly not anytime soon).

So even if we did update to show build labels on projects with an unknown prognosis, it wouldn't solve your problem.

Do most CI servers even let you add projects with the same name? I don't think either Jenkins or GoCD allow this, which are the CI servers I've used the most.

Can you provide an anonymised copy of your CCTray XML feed? It might help me better understand exactly what is going on.

As an aside:

You've mentioned a self built ccmenu server and gitlab. Is gitlab your actual CI server and the self built ccmenu server just providing the CCTray XML feed for it? If that's the case there currently is an issue to add CCTray XML support to gitlab, which doesn't seem to be gaining much traction but might still be worth checking out.

galan commented 5 years ago

Hi @GentlemanHal, thanks for clarifing some of the issues you encountered while developing nevergreen. It might be that I'm violating the label field, because the ccmenu xml structure is too limited. Nevertheless the branches we build should be also in the build-overview, and the representation looks better then in the actual name. So you suggest to use the branch name as part of the ccmenu project name? That would look like fusion-reactor (master) or fusion-reactor (task/TICKET-123-refactor-whatever). This could lead to very long names. I attach an anonymised ccmenu feed that might help you getting an overview of what I'm doing (actually the projects with state unknown are pipelines which are skipped (there is no status for that in ccmenu either)). ccresult-anon.xml.zip

For the record, we have about 150 repositories, each having pipelines for master and branches, which might lead to > 200 projects in the ccmenu xml. Luckily the nevergreen shows only the failed pipelines. However, branches come and go, and the ccmenu.xml is reflecting this. It seems that nevergreen only shows the projects that where configured manually, is this correct? (I would open a new issue for that)

As for the gitlab issue you mentioned, yes I think this would solve that ticket and I keep an eye on that, thanks for the hint. The project still needs some polishing, it is meant to be a generic aggregator for gitlab-pipeline overview dashboards. I'll give you feedback as soon it is public available.

GentlemanHal commented 5 years ago

So you suggest to use the branch name as part of the ccmenu project name?

Yes, this is what other CI servers do such as GoCD and CircleCI. The last build label is traditionally just the numeric build number.

Edit: Here is the closest thing to an official spec that probably exists, https://github.com/erikdoe/ccmenu/wiki/Multiple-Project-Summary-Reporting-Standard

For example GoCD has the concept of pipelines, stages and jobs, this information is represented in the name:

<Project name="example-service :: stage-1 :: job-1" ...snip... />

and CircleCI includes the owner:

<Project name="owner/example-service" ...snip... />

You can see some example CCTray XML files in the CCTray XML feed mock server in the Nevergreen source.

Nevergreen attempts to auto detect the CI server (you can also manually select in the tray options) so it can pass out this additional information in the name.

It seems that nevergreen only shows the projects that where configured manually, is this correct?

This is correct, Nevergreen currently only shows projects that have been configured for display. If projects are added or renamed you will have to go back to the Tracking page, refresh and select the new projects.

This is actually what we plan to tackle for the next major release and the full history and our current thinking can be found in issue #265. Feel free to give that and read and add any thoughts or comments 😄

galan commented 5 years ago

Hi @GentlemanHal , I have finished the work on the ccmenu-server, which acts more like a hub for the gitlab-pipeline states now. Beside the ccmenu, I also provide other output formats, such as html, shell and prometheus.

The project is open-source and can be found here: https://github.com/joblift/gitlab-panorama

For my use-case this leads to the point, that I don't require nevergreen anymore. However, the ccmenu endpoint from GitLab panorama can be used to provide the input for nevergreen, if this visualization is preferred. Looking forward for your next release.

You might update the https://github.com/build-canaries/nevergreen/wiki/find-cctray page for GitLab.