All the other VERSION ARGS in the Dockerfile are pure version numbers.
Any other additions are handled elsewhere.
Arguably, this is just cosmetic/foolish consistency, but it is a source
of subtle bugs. For example, the fallback if `bun -version` fails is
defined here:
af1d77abfb/railties/lib/rails/generators/app_base.rb (L19)
Note the _lack_ of bun_v, which ultimately will cause the docker build
to fail.
* Update 7_1_release_notes.md
For context see https://github.com/rails/rails/pull/45867
Include in release notes the deprecation of `true` and `false` values
for `config.action_dispatch.show_exceptions` in favor of `:all`,
`:rescuable` and `:none`.
* Update 7_1_release_notes.md
Co-authored-by: Hartley McGuire <skipkayhil@gmail.com>
---------
Co-authored-by: Hartley McGuire <skipkayhil@gmail.com>
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
Change mentions of `app/views/shared` in the guides to be
`app/views/application` instead. View partials rely on the same
[Template Inheritance][] as their template counterparts, so the guides
should encourage end-users to benefit from that inheritance.
> This makes `app/views/application/` a great place for your shared
> partials, which can then be rendered in your ERB as such:
>
```html+erb
<%# app/views/admin/products/index.html.erb %>
<%= render @products || "empty_list" %>
<%# app/views/application/_empty_list.html.erb %>
There are no items in this list <em>yet</em>.
```
To enforce that template resolution, this commit also replaces
references to `shared/` with `application/` in the Rails test suite.
[Template Inheritance]: https://guides.rubyonrails.org/layouts_and_rendering.html#template-inheritance
This commit fixes the issue where the `primary_key:` option was ignored
if the associated model had a `query_constraints` configured.
Now `primary_key:` option always takes priority and only if there is no
`primary_key:` option, the `query_constraints` are used to determine
the `association_primary_key` value.
Following up on https://github.com/rails/rails/pull/49192, this commit
adds the transaction `outcome` to the payload, helpful for collecting
stats on how many transactions commit, rollback, restart, or (perhaps
most interestingly) are incomplete because of an error.
The one quirk here is that we have to modify the payload on finish. It's
not the only place this sort of thing happens (instrument mutates the
payload with exceptions, for example), but it does mean we need to dup
the payload we initialize with to avoid mutating it for other tracking.
Co-authored-by: Ian Candy <ipc103@github.com>