gradle-baseline
gradle-baseline copied to clipboard
Fix typos and links
Before this PR
- Some typos
- Switch links from HTTP -> HTTPS (I believe that is safe and recommended these days)
- Some links have changed address. The old address is still usable, but these are the addresses you get redirected to
After this PR
==COMMIT_MSG== Fixed typos and link updates ==COMMIT_MSG==
Possible downsides?
- One typo is in a markdown header, which can break existing links outside of the readme.
- I guess there is an argument to be made that these link doesn't need to be HTTPS
Other
Feel free to comment on any of the changes/commits and I can update them accordingly. I don't have any issues reverting/removing anything in this PR or splitting it over multiple PRs if that makes more sense.
This is just me being nitpicky X)
Generate changelog in changelog/@unreleased
changelog/@unreleased
Type
- [ ] Feature
- [ ] Improvement
- [x] Fix
- [ ] Break
- [ ] Deprecation
- [ ] Manual task
- [ ] Migration
Description
Check the box to generate changelog(s)
- [x] Generate changelog entry
Hi @k3KAW8Pnf7mkmdSMPHz27 , thanks for your contribution. Overall this looks good, and definitely appreciate fixes & switch from http to https.
I think the original CI automated doc linting in https://github.com/palantir/gradle-baseline/blob/develop/docs/lint.sh by https://github.com/palantir/gradle-baseline/pull/127/ was dropped with the move to Circle templates. I know we've had some problems in the past with build flakes due to doc linting URL check transient failures, but might be worth updating lint.sh to expand the remark rules and add some dead link checks via remark-lint-no-dead-urls and maybe also flag any http
schemes so we can warn, but not fail builds to prevent similar future issues.
Hello @schlosna, thank you for mentioning remark-lint, you just made me go on a one-hour-long Reviewdog tangent ^^
Circle templates. I know we've had some problems in the past with build flakes
I haven't used circle-ci so I can't be useful with that. Creating a new non-required workflow would be my default go-to method
also flag any http schemes so we can warn, but not fail builds to prevent similar future issues.
I am going to dig through remarks-lint's plug-in documentation. It appears to be a more fully-featured markdown-linter than what I've been using elsewhere and creating a workflow that can warn/automate upgrades to HTTPS if the linked-to server supports it would be the icing on the cake.
I haven't had the time to look at this PR in a very long time, and I strongly suspect it is all outdated.