* ci: Revise `question.yml` to better clarify the issue tracker is not for support queries
Users have been making low effort reports (_bypassing the dedicated form_) through this alternative that is intended for addressing other concerns related to the project - not troubleshooting user problems.
When a user does not want to put the effort in of a full bug report (_and following our debug docs tips that it refers them to_), they should be using the Github Discussions page which provides the same free-form input, but should not require attention of project devs (contributors / maintainers).
---
The markdown rendered field above the "Description" input field didn't seem too relevant for this template. I've opted for a markdown comment (so it won't render if kept) into the input field with hopes that'll be more visible to the readers attention.
* chore: Fix typo
docs: Add compatibility section to debugging page
ci: Adjust bug report template
Reduce some text + compress the preliminary checks down to single check item.
Simplify the bug report form further by dropping / merging form sections.
Change Overview:
- Minor revisions and formatting changes (_multi-line pipe operator, emoji, fix typos, etc_).
- Collapsed OS + Arch into single input field (_not much benefit from the two additional dropdown items_).
- Description/reproduction and expectation sections revised (_expectation intent is typically inferred by the issue description, while detailed reproduction steps can belong a separate optional section_).
- Removed platform dropdown (_Windows and macOS are mentioned in description as unsupported_).
- Removed experience checkboxes (_context doesn't really change responses_).
- Removed the orchestrator dropdown (_we don't seem to use this information, it's just noise_)
- Relocate the DMS version + OS/Arch sections to come after the Reproduction steps.
Misc spelling fixes and resolved imprecise statements. Shortened the bug
report introduction a bit further and added a statement about being
precise to all templates.
* docs: change some absolute links to relative links
* docs: change most hard-coded links to `edge` to point to `latest`
* Apply suggestions from code review
* docs: revert 404 page to edge and change canonical link to `latest
---------
Co-authored-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>
Co-authored-by: Georg Lauterbach <44545919+georglauterbach@users.noreply.github.com>
If permissions are specified at the workflow level, any that are not explicitly set became `none` and jobs cannot request that to change.
Permissions are therefore scoped to the job itself.
* ci(fix): Temporarily avoid specifying `provenance`
As the test workflow does not use the `docker-container` buildx driver, it uses the Docker Engine bundled BuildKit version which until v23 release does not support attestations.
Likewise the current buildx version in CI is `0.10.0` which does not respect `--provenance false`, the presence of the option appears to trigger a BuildKit version compatibility check and fail early before it considers the value of the option.
* chore: Use buildx `docker-container` driver instead
An alternative solution to omitting `provenance: false` (_not supported by buildx 0.10.0 with default `docker` driver when Docker Engine bundles BuildKit less than 0.10.0, which is the case prior to the Docker Engine v23 release_).
This approach provides more consistency with the build and publish workflows by using the same buildx `docker-container` driver (_and thus newer BuildKit, enabling support for `provenance: false`_).
* chore: Revise test workflow inline docs
Buildx `docker-container` driver is not needed here, but it does seem like it improves cache-hit ratio when building from the retrieved build cache (from the earlier build workflow). Possibly due to building with the same BuildKit version.
