Tasks #47338
open
mgr/dashboard: Add E2E test to check external links
Added by Lenz Grimmer over 3 years ago.
Updated almost 2 years ago.
Description
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.
- Project changed from mgr to Dashboard
- Category changed from 151 to Testing & QA
Emmanuel Opatola is handling this issue.
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.
- Assignee set to Emmanuel Opatola
- Status changed from New to In Progress
- 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