Wiki/Reporting: update example output for `gitblame` reports
The generation of the output examples for the `gitblame` report cannot easily be automated for the following reasons:
1. If using code samples committed to this repo, there would (for now) only be one author, making the output example not a very good example.
2. If generating these output examples from an existing codebase, there may be privacy issues in play when using the handles/names of real developers.
All in all, for now, the output has been manually updated to use the current report format, but using fake data.
Wiki/Reporting: improve report display
Wiki: various grammar and spelling fixes
Wiki: always use fully qualified links
GH Actions: add a workflow to automatically deploy the wiki
This commit introduces a workflow, which will:
* Automatically deploy the wiki files to the [PHP_CodeSniffer repo wiki](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki) on every push to the `main` branch.
* Will do a dry-run, without actually deploying, whenever a PR is created which would update the wiki files.
This way, the wiki is opened up to contributions via pull requests and is no longer limited to only edits made by committers.
A prominent warning is automatically added as a (hidden) comment at the top of each wiki file to warn committers not to edit the wiki file in the GitHub wiki interface.
Any edits made via the GitHub wiki interface or by directly pushing to the wiki repository, will be lost and overwritten via this workflow the next time a change is pushed to the `main` branch of this repo.
This commit also adds a `_Footer.md` file, which will automatically be displayed at the bottom of each wiki page to point out that the wiki is editable via PRs to this repo.
Notes:
* The files are copied to a `_wiki` directory - which is `.gitignore`d - before pre-processing to reduce the risk of the source files being accidentally updated (and committed), which would undo the automation.
* Commits for "push" events to the `main` branch will get the same commit message for the wiki as the _last_ commit on the `main` branch.
For that reason, merge commits are not allowed in this repo and PRs with only one commit are strongly preferred.
* Dry-run commits for PR events and commits triggered by other events, will get a simplified message referencing the sha of the last commit.
* If the net effect of a commit results in no changes to the wiki files (CI changes and such), no commit will be made to the wiki.
* The workflow is set up to fail if GitHub has an outage for git operations.
That should protect the wiki from going down by a broken/partial commit and allows for retriggering a deploy once the outage has passed by re-running the failed build.
Future scope (upcoming):
* Automate generation of the Table of Contents for wiki pages.
* Automate re-generation of output examples used in the wiki pages.
Refs:
* https://github.com/Andrew-Chen-Wang/github-wiki-action
* https://github.com/crazy-max/ghaction-github-status
Fixing errors/Reporting: move Diff report info
The information about the `Diff` report was included in the "Fixing errors automatically" page, but is kind of dated as the `phpcbf` script has by now existed for a fair number of years.
This changes the "Fixing errors" page to focus on the `phpcbf` tool and moves the information about the "Diff" report to the "Reporting" page.
jrfnl
committed
May 9, 2025
Remove ablist language and other textual improvements
jrfnl
committed
May 8, 2025
CS/markdownlint: various whitespace fixes
jrfnl
committed
May 8, 2025
CS/markdownlint: use fenced codeblocks everywhere
This makes it easier to copy/paste updated output to the wiki docs.
jrfnl
committed
May 8, 2025
Merge progress reporting sections
When I created the new section about progress reporting on the "Reporting" page, I'd overlooked that the "Usage" page already contained a section on progress reporting.
This commit now removes the section from the "Reporting" page again and merges some of the information which was contained in that section, into the information about progress reporting on the "Usage" page.
Includes various tweaks and updates to the pre-existing information:
* Make it explicit how progress reporting can be enabled.
* Shorten the example output for progress.
* Mention the name of the configuration option to enable progress reporting by default.
* Refresh the example output for the verbose example.
jrfnl
committed
May 7, 2025
Reporting: add section about progress reporting
jrfnl
committed
Apr 13, 2025
Update sniff code vs error code + additional info about this in Reporting and Advanced Usage
Refs: #319, #328
Co-authored-by: Joachim Noreiko <joachim@107701.no-reply.drupal.org>
jrfnl
committed
Feb 6, 2024
Reporting: add note about caching vs Performance Report
Related to #306
jrfnl
committed
Jan 27, 2024
Add information about the new Performance report
Ref: https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/60
jrfnl
committed
Nov 12, 2023
Add "back to top" links under each section
... on long pages which contain a table of contents.
jrfnl
committed
Nov 12, 2023
Use highlighted blocks for important information
Ref: https://github.com/orgs/community/discussions/16925
jrfnl
committed
Nov 12, 2023
Updated Reporting (markdown)
Updated Reporting (markdown)
Updated Reporting (markdown)
Updated Reporting (markdown)
Updated Reporting (markdown)
Added docs for code report
Updated Reporting (markdown)
Updated Reporting (markdown)
Added junit report type + updated all report output for latest version
Updated Reporting (markdown)
Updated Reporting (markdown)