Tasks #47338

mgr/dashboard: Add E2E test to check external links

Added by Lenz Grimmer about 3 years ago. Updated over 1 year ago.

Fix Under Review
Testing & QA
Target version:
% Done:


Affected Versions:
Pull request ID:


The Dashboard contains several locations that point to external documentation pages for reference purposes (e.g. how to configure certain services like Grafana or RGW).

As these links are not maintained by us directly, we should at least perform a check if following these links actually get us to the expected page or result in a 404 error.

Creating an E2E test might be the best approach for this.


#1 Updated by Ernesto Puerta over 2 years ago

  • Project changed from mgr to Dashboard
  • Category changed from 151 to Testing & QA

#2 Updated by Laura Flores over 1 year ago

Emmanuel Opatola is handling this issue.

#3 Updated by Ernesto Puerta over 1 year ago

Apart from the e2e testing approach, there might be better ways to test this:
  • Angular unit tests: given the external URLs are known at "build" time, we wouldn't really need to wait for the e2e stage. This would be very quick to test.
  • Link search tool: the above approach would still involve manually adding a test for every new URL added. However, we could instead look for links in Dashboard Angular codebase (src/pybind/mgr/dashboard/frontend/src/app/...), such as "http://", "https://" or "href=<>" attributes. However, URLs in comments need to be excluded from this testing and URLs with string interpolation/templates would be tricky.
I just grep'ed the code base and the external links basically come from:
  • shared/services/doc.service.ts: the doc-service. This will require a unit test, since it dynamically generates URLs from a template, so you cannot actually "grep & curl" the url. The pro is that all the links used by that service can be programmatically tested.
  • Telemetry: shared/components/telemetry-notification/telemetry-notification.component.html and ceph/cluster/telemetry/telemetry.component.html. Same thing, probably a unit tests will be enough for these... And if they're moved to a service like the existing Doc Service (e.g.: a Link Service), all the testing can be easily automated too.
  • iSCSI: some Wikipedia link in ceph/block/iscsi-target-form/iscsi-target-form.component.html (same approach: new "Link Provider service")

So, summarizing, if we move hard-coded URLs/links from the source code and move them to a centralized service (similar to the existing Docs Service, but with a new name, like Link Provider Service or something), we can easily iterate over the collection of links in a unit-test.

#4 Updated by Emmanuel Opatola over 1 year ago

  • Assignee set to Emmanuel Opatola

#5 Updated by Emmanuel Opatola over 1 year ago

  • Status changed from New to In Progress

#6 Updated by Emmanuel Opatola over 1 year ago

  • Status changed from In Progress to Fix Under Review

Created a service - link-provider service and the corresponding spec file.

Also available in: Atom PDF