I was getting this error when I tried building an image:
: failed to create LLB definition: rpc error: code = Unknown desc = error getting credentials - err: exit status 255, out: ``
Restarting WSL didn’t help, but I found out that disabling the buildkit does fix it.
DOCKER_BUILDKIT=0 docker build ...
See SO answer.
These are definitely listed in the Rails guide, but I rarely see anyone use these so I wasn’t aware they existed!
Type Modifiers are listed here. Things like, setting default values, null constraints, and character limits. Apparently, you can specify some of them in the generator command.
Of course, they don’t just TELL you which ones you can use 😩 that would be too easy. After searching for a long while I found the source code and I think these are the only currently supported modifiers:
limit: Sets the maximum number of characters for a string column and the maximum number of bytes for string/text/binary/integer columns.precision: Specifies the precision for decimal/numeric/datetime/time columns.scale: Specifies the scale for the decimal and numeric columns, representing the number of digits after the decimal point.polymorphic: When generating with references, this option will create two columns which can be used for polymorphic associations: <column_name>_type and <column_name>_id.To specify these modifiers, you need to pass values enclosed in curly braces after the field type like this:
rails g migration AddNameToUsers name:string{40}
rails g migrationAddAmountToProducts amount:decimal{10.2}
You must set both precision and scale at once.
rails g migration add_supplier_to_products supplier:references{polymorphic}
A third value can be specified using another : after the column name and type, to configure the index of the column. This could also be the second option if the column type is a String.
:index: will just add an index
add_column :products, :amount, :string
add_index :products, :amount
:uniq: will add unique: true in the migration.
Migration names containing JoinTable will generate join tables for use with has_and_belongs_to_many associations.
rails g migration CreateJoinTableCustomerProduct customer product
will create the migration:
def change
create_join_table :customers, :products do |t|
# t.index [:customer_id, :product_id]
# t.index [:product_id, :customer_id]
end
end
Nice.
Try re-authenticating with Docker Desktop and then restart Docker, WSL, and VSCode (which should say something like “updating”).
Then you should be good to go.
(trying to log in via CLI in WSL won’t work don’t try)
Sometimes the multiple ways that variables are passed to partials confuses me.
Using locals, whenever you render a partial you must declare the same variable. If you attempt to render the same partial in a different view template without declaring the same local variable, you’ll get an error.
<%= render :partial => 'form', :locals => { :post => @post } %>
In cases where sometimes you want to pass a variable to a partial but other times you don’t, use local_assigns. Be aware that you will need to check for the existense of a variable in the partial before you use it.
<%= render article, full: true %>
<!-- in template -->
<h2><%= article.title %></h2>
<% if local_assigns[:full] %>
<%= simple_format article.body %>
<% else %>
<%= truncate article.body %>
<% end %>
Every partial also has a local variable with the same name as the partial (minus the leading underscore). You can pass an object in to this local variable via the :object option:
<%= render partial: "customer", object: @new_customer %>
If you see the super shorthand syntax:
<%= render @customer %>
it uses object: @customer.
These work essentially the same as with single object view partials. To customize the name of the local variable, use the :as option:
<%= render partial: "product", collection: @products, as: :item %>
You can also still create local variables using locals like before:
<%= render partial: "product", collection: @products,
as: :item, locals: {title: "Products Page"} %>
Read more in the Rails Guide.
Since the removal of the free Heroku plan, most of my throw-away prototype apps that I deployed have been shutdown. However, there are a few of them that don’t use a database that I expected to continue to work when Heroku shut off the database but didn’t.
I did a little research and found that you can reconfigure a Rails app to not use a database. This allowed my apps to run purely on the new Eco dynos, without paying for the database connection.
The steps I followed to reconfigure my Rails 6 app are as follows:
Comment out/remove the following:
// package.json
"@rails/activestorage": "^6.0.0",
// app/javascript/packs/application.js
require("@rails/activestorage").start()
# bin/setup
system! 'bin/rails db:prepare'
# config/environments/development.rb
config.active_storage.service = :local # For Rails >= 5.2
config.active_record.migration_error = :page_load
config.active_record.verbose_query_logs = true
# config/environments/test.rb
config.active_storage.service = :test # For Rails >= 5.2
# config/environments/production.rb
config.active_storage.service = :local # For Rails >= 5.2
config.active_record.dump_schema_after_migration = false
# spec/rails_helper.rb
ActiveRecord::Migration.maintain_test_schema!
# test/test_helper.rb
fixtures :all # In case you're using fixtures
# Only for Rails >= 5.0
#config/initializers/new_framework_defaults.rb
Rails.application.config.active_record.belongs_to_required_by_default = true
Delete app/models/application_record.rb.
You can run your Rails app in production mode locally to make sure there are no errors.
RAILS_ENV=production rails assets:clobber
RAILS_ENV=production rails webpacker:compile # assuming you have webpacker
RAILS_SERVE_STATIC_FILES=1 RAILS_ENV=production rails s
If there are no errors (with the exception of missing Heroku ENV keys), then you should be good to go!
If you are creating a new Rails app from scratch and don’t want to use a database, you can run rails new with the --skip-active-record flag.