For Rails 7.2 we will make devcontainer and opt-in feature for new applications. When creating a new app, you can generate a devcontainer by passing the --devcontainer flag.
Currently when you generate a project the compose.yaml generated
file does not include the top-level name property. Not having this
top-level name property makes all containers / volumes started by
devcontainer to be prepended with the folder name, which is
`devcontainer` in the case of the .devcontainer/compose.yml` file.
This is ok if you run only one project with devcontainer but starts
to get problem if you run multiple projects. If you have one project
that runs on postgresql 15 and a new one that runs on postgresql 16 it
will fail to boot the postgresql container because both devcontainers is
using the same volume: `devcontainer_postgres-data`.
This commit fixes this by setting the top-lavel name property with
the project name, which will make the containers and volumes to be
prepended with the project name and not with `devcontainer`.
GitHub Actions spams the commit status with one for each job.
We want to keep the number of statuses to a minimum, so we can see the
main buildkite status, so we should run all the tests in a single job.
When we run the smoke test on main, we push the devcontainer images to ghcr to be used as a cache for future workflow runs. This causes an error on forks because they don't have permission to push (which is good). So, let's set the step to never push if the repo is a fork. The github context doesn't have a way of checking if the repo is a fork, so I check the repo owner instead, but that's ok since it's the repo owner (rails) who has permissions to push the package.
This workflow tests the generated devcontainer for new rails apps by:
- Generating a new app with the --dev flag
- Initializing the dev container that is generated
- Generating a model scaffold and running the migrations
- Running the tests
It tests each of the four supported database configurations.
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.
Jean Boussier