There are valid use cases for running SQLite in production, however it must be done
with care, so instead of a warning most users won't see anyway, it's preferable to
leave the configuration commented out to force them to think about having the database
on a persistent volume etc.
Co-Authored-By: Jacopo Beschi <beschi.jacopo@gmail.com>
Since a GH token is required for the action-discord notify action to fetch the commit message, otherwise it would make unauthenticated requests leading to rate limiting. This shouldn't impact the result of a workflow, but it's annoying.
The permissions for this token can vary based on the repository's settings. So to ensure we don't accidentally get a token with write access or something, we should use restrictive permissions per workflow, like the other workflows in this project.
See: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token
* Removed 'fixed/still failing' modes
* Only runs when failure() step
* Include GITHUB_TOKEN to prevent rate-limits
* Need to reset BUNDLE_ONLY on rubocop job
Your Gemfile lists the gem rake (>= 13) more than once.
You should probably keep only one of them.
Remove any duplicate entries and specify the gem only once.
While it's not a problem now, it could cause errors if you change the version of one of them later.
This is a follow up to rails#47186, this time for all markdown content.
[markdownlint](https://github.com/markdownlint/markdownlint) is an excellent tool, and I've found it very useful for finding issues in the guides.
Many of the rules are common style issues I'm correcting on PRs, so it will be nice to have that automated.
We should also be able to use the same config with our editors, so that errors show up in real-time 🙏 and will update the contributing docs once this gets merged with how to debug and use mdl appropriately.
This linter parses the Rails::Application::Configuration file and
ensures that
- all configurations are listed alphabetically in Configuring guide
- all framework defaults are listed alphabetically in Configuring guide
- all framework defaults are included in the new_framework_defaults_x_x
template
Also bumped rubocop, rubocop-minitest, rubocop-performance and rubocop-rails
because RuboCop workflow uses Gemfile.lock unlike Rails CI that removes it.
You can't check if "CI is passing" until you create a PR, because for most people Buildkite will only run the build when a PR is created (It will run on branch push only if you push to a branch of the `rails/rails` repo, which only people with write access can do.). So we shouldn't tell people to wait for CI to pass before submitting a PR.
This PR just tweaks the CI template to explain this in a comment so that people know to check back once CI has actually run.
I've noticed a few PRs made since the latest template update, that have said things like "this PR was created because of #ISSUE" or things along those lines. It seems like people are reading the template and following its advice! But Github requires a specific syntax to auto-close an issue, so we may as well encourage people to use that to save everyone a bit of time. So in this PR I've added a comment to the template explaining that.
I think no one is reading this because I've seen an increase in draft
PRs. To fix that I've moved the draft statement to the top. I also think
the number of check boxes is a lot and isn't resulting in better PRs
because the length means they are not being read. I removed ones that I
think are repetitive or unhelpful. I wish I could A/B test this...
Two things were changed:
- line number are added to errors so its easier to find them
- blank lines with trailing whitespace now correctly show 1 error
(trailing whitespace) instead of 2 (trailing whitespace + wrong
indentation)
As the codespell dictionary changes between versions, we should declare
explicitly the version we are ready for so that this CI doesn't break
every time there is a new version.
Ideally this would be upgraded periodically to catch new errors, but I
don't think the need is urgent enough for us to fail CI on PRs.
There have been a number of recent commits introducing incorrectly
formatted CHANGELOG entries:
- 9f0b8eb was missing an author
- 936a862 had trailing whitespace
- 238432d had wrong number of leading whitespace
- 51852d2 had wrong number of leading whitespace in the header
To prevent these inconsistencies from happening in the future, I wrote a
small linter for CHANGELOG files that catches all of the above errors.
The major change is to add checklist so that it's easier to be read
than comments.
Also, `Summary` is not clear about what should be written, so here
it's changed to `Motivation` and `Detail`.
Finally, it clearly says they can discard this template if they need to.
While the idea of cleaning up the the PRs list by nudging reviewers
with the stale message and closing PRs that didn't got a review in time
cloud work for the maintainers, in practice it discourages contributors
to submit contributions.
Keeping PRs open and not providing feedback also doesn't help with
contributors motivation, so while I'm disabling this feature of the bot
we still need to come up with a process that will help us to keep
the number of PRs in check, but celebrate the work contributors already
did instead of ignoring it, or dismissing in the form of a "stale"
alerts, and automatically closing PRs.
If the `client9/misspell` repo is compromised, an attacker could control
the contents of `install-misspell.sh`. Since we execute that file
directly, we should use a URL that guarantees its contents will not
change.
Note that, at the time of writing, the last commit to `client9/misspell`
was in March 2018 (client9/misspell@c0b55c8239),
so the code appears to be stable.
Also, although using a tag would be prettier than using a hash, the
repo's last commit is after its most recent tag (`v0.3.4`).
A lot of bug reports have useful reproduction steps that could be a reproduction script, but they seem to have either not found the reproduction script template or didn't read the 'contributing to rails' page at all. This links to the same page at the section that includes the reproduction scripts with a stronger call to action making it clear that they need a reproduction script.
`codespell` works with a small custom dictionary and seems to find perhaps more spelling mistakes than `misspell` which really only fixes commonly misspelled English words.
Not all spell checkers can check all file types and most spell checkers can't find all the errors.
https://github.com/codespell-project/codespellhttps://pypi.org/project/codespell/
Jean Boussier