-
Notifications
You must be signed in to change notification settings - Fork 6
Publish to gh pages #50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
grafana-image: grafana-enterprise | ||
plugin-name: ${{ matrix.plugin-id }} | ||
test-outcome: ${{ steps.run-tests-latest.outcome }} | ||
# repeat steps but for another Grafana version if necessary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not quite clear why it would be necessary, isn't it an example for matrix test with multiple grafana versions? (from mobile so maybe did not look it up properly)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No for this example, the matrix resolves multiple plugins. Could for example be in a monorepo where you repeat per plugin. Not sure how common it would be, but basically just want to highlight that it can be used in many different ways.
This PR introduces two GitHub Actions to streamline the process of managing Playwright test reports. Publishing the reports to GH Pages instead of GCS (like this existing publish-report Action does) has several advantages. Using GH pages brings this capability also to the community. It also allows GH enterprise customers to configure access control for GH pages, allowing them to use secrets within their e2e tests.
Github already offers a set of Actions that can be used to publish pages. But they're not suitable for this scenario for the following reasons:
deploy-report-pages
deletes any published reports older than the specified retention period.I know putting these two actions in a parent directory breaks the convention in this repo, but they are so tightly coupled so I thought it still makes sense. Happy to hear your thoughts on this.
See example of the actions being used in a standard datasource plugin here.
Example usage in the plugin-examples repo here