Is your enhancement request related to a problem on existing feature? Please describe.
Naah!
Describe the solution you'd like
At this point, it is just an idea. Need to check if a GitHub action workflow can detect the todo tag and fail the workflow for the developer to manually check and finish the TODOs.
Describe alternatives you've considered
If automation on this doesn't work (or too much of hard work for this simple thing), we have to stick to manually checking before approving the PRs (for todo tags on both PR & issue).
Initial thought of adding todo is to signify that the issue or PR has some action items which have to be converted as issues. But this can be open-ended in future.
TODO (if any)
Add details of what todo tag does, as explained above, in CONTRIBUTING.md
Ownership of Contribution
If the triage is approved,
I wish to submit the PR myself.
I wish to submit the PR. But if someone is willing to do it, go ahead.
I don't know how to fix this or make these changes. I wish others to pick this up for me.
Is your feature request related to a problem? Please describe.
Currently, we only check coverage in local run with manual validation. Need to automate for CI/CD.
Describe the solution you'd like
Need a script that will fail if the expected threshold is not met. This can then be run from GitHub actions on every push or PR.
Describe alternatives you've considered
Make target would also do the trick. But as the commands grow in size, it gets a hassle to overload makefile.
Additional context
GitHub actions already have the unit test run workflow(s). Just need to add a separate workflow of coverage check.
If using a script, it should run on bash (zsh user myself, I still think bash is the standard). Syntax differences of different shells or WSL is a headache of the future developers.
Ownership of Contribution
If the triage is approved,
I wish to submit the PR myself.
I wish to submit the PR. But if someone is willing to do it, go ahead.
I don't know how to fix this or make these changes. I wish others to pick this up for me.
Currently, all examples are on README.md making scroll forever. Need to move them to a directory examples/ with respective document names and hyperlinks, except for installation and examples (which only has 3 code blocks).
Since this is a fork, gorilla/mux v1.8.0 should be released as v0.0.0 here.
Describe the Solution You Think
Since gorilla mux is just a package and not a cmd tool, no releasers like goreleaser be used. However, the release page might need the source code section as in gorilla/mux v1.8.0.
The release page might require a template consisting
Release version details
Change log
Contributors
I've added release-drafter to the project. Hence the template changes have to be done in .github/release-drafter.yml. However, I'm not sure how to release the first-ever version.
Additional Context
Refer release-drafter for more info on how to fix the template and to release.
Ownership of Contribution
If the triage is approved,
I wish to submit the PR myself.
I wish to submit the PR. But if someone is willing to do it, go ahead.
I don't know how to fix this or make these changes. I wish others to pick this up for me.