6fa53a1ee4
* Alerting: Opsgenie send tags as extra properties Allow users to select where to send notification tags when alerting via OpsGenie. Supports sending tags as key/value details, concatenated strings in tags or both. Users will be able to see their tags as key/values under extra properties in an alert on the Opsgenie UI. These key/values can then be used in the platform for routing, templating etc. * Configurable delivery to either tags, extra properties or both * Default to current behaviour (tags only) * Support both so users can transition from tags to details Add docs and clean up references * Alerting: Add additional arg for Opsgenie tests The NewEvalContext function now requires a 'PluginRequestValidator' argument. As our test does not use the validator we can specify 'nil' to satisfy the function and allow our test to pass as expected. * Alerting: Opsgenie doc fixes Accept suggested changes for Opsgenie docs Co-authored-by: achatterjee-grafana <70489351+achatterjee-grafana@users.noreply.github.com> * Alerting: Opsgenie provisioning settings docs Add the new setting to the provisioning docs * Alerting: Opsgenie doc typo correction Move the comma (,) out of the preformatting tags for the setting value * Alerting: Opsgenie refactor send switches Refactor the send switches to be methods on the OpsgenieNotiefier itself. This also cleans up the method names so that the code reads a bit more logically as: if we should send details: send details if we should send tags: send tags This avoids the calling code needing to care about passing the state and allows an engineer working in the `createAlert` function to focus on the results of applying the logic instead. * Alerting: Opsgenie docs rename note Rename the note heading to match the number to more clearly link them. * Alerting: Opsgenie use standard reference to note Refer to the note below as per recommendation and standards. Fixes #30331 Co-authored-by: achatterjee-grafana <70489351+achatterjee-grafana@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| sources | ||
| .gitignore | ||
| logo-horizontal.png | ||
| Makefile | ||
| README.md | ||
Building the docs locally
When you contribute to documentation, it is a good practice to build the docs on your local machine to make sure your changes appear as you expect. This README explains the process for doing that.
Requirements
Docker >= 2.1.0.3 Yarn >= 1.22.4
Build the doc site
- On the command line, first change to the docs folder:
cd docs. - Run
make docs-quick. This launches a preview of the website with the current grafana docs athttp://localhost:3002/docs/grafana/latest/which will refresh automatically when changes are made to content in thesourcesdirectory.
If you have the grafana/website repo checked out in the same directory as the grafana repo, then you can run make docs-local-static to use local assets (such as images).
Content guidelines
Edit content in the sources directory.
Using relref for internal links
Use the Hugo shortcode relref any time you are linking to other internal docs pages.
Syntax is:
{{< relref "example.md" >}}
You might need to add more context for the link (containing folders and so on, folder/example.md) if Hugo says the relref is ambiguous.
Edit the side menu
The side menu is automatically build from the file structure. Use the weight front matter parameter to order pages.
Add images
Images are currently hosted in the grafana/website repo.
Deploy changes to grafana.com
When a PR is merged to master with changes in the docs/sources directory, those changes are automatically synced to the grafana/website repo and published to the staging site.
Generally, someone from marketing will publish to production each day: so as long as the sync is successful your docs edits will be published. Alternatively, you can refer to publishing to production if you'd like to do it yourself.