This PR allows to adjust the categories and matching labels. If no label
matches, "Support" is the old hardcoded default.
Issues with the "Documentation" and "ITL" label will be put into their
respective category at the bottom before "Support". This increases readability
and allows users to focus on the core vs additional config and docs.
"Support" also applies to labels such as "code-quality", "Tests" and "Packages"/"Installation".
Note: Labels are case sensitive. The order of the categories dictionary is
important too.
Since issues and PRs are the same for GitHub, and we don't require an issue
for a PR anymore, we sometimes have duplicates. This patch adds an inline
label called "PR" to highlight these PRs in the Changelog.
refs #5989
This PR allows to adjust the categories and matching labels. If no label
matches, "Support" is the old hardcoded default.
Issues with the "Documentation" and "ITL" label will be put into their
respective category at the bottom before "Support". This increases readability
and allows users to focus on the core vs additional config and docs.
"Support" also applies to labels such as "code-quality", "Tests" and "Packages"/"Installation".
Note: Labels are case sensitive. The order of the categories dictionary is
important too.
Since issues and PRs are the same for GitHub, and we don't require an issue
for a PR anymore, we sometimes have duplicates. This patch adds an inline
label called "PR" to highlight these PRs in the Changelog.
This fix is only needed for a fresh 2.8.0 setup, older versions
and upgrades to current do not need this (can be applied as idempotent
update).
fixes#5947
refs #5986
This fix is only needed for a fresh 2.8.0 setup, older versions
and upgrades to current do not need this (can be applied as idempotent
update).
fixes#5947
The `process-check-result` action can now optionally set the
`ttl` parameter. This overrules the configured freshness
check (check_interval).
The main idea behind this is to allow the external sender
to specify when the next check result is coming in.
For example, a backup script which should be run every
24h can specify the exact expected next check result.
The addition to the CheckResult class is necessary to
forward the check result throughout the cluster and
calculate the `next_check` value on each node. This
allows us to send in a check result on a satellite,
and the master determines the freshness and possible
notifications/state changes for Icinga Web 2.
