Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Add preboot context to strong_migrations destructive-operation messages

Aperta Adatta ai principianti
#2,963 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
ruby
Ambito
databases, devops

Direzione di ricerca

Inizia da config/initializers/strong_migrations.rb e dall’elenco delle chiavi strong_migrations in lib/strong_migrations/error_messages.rb, concentrandoti sulle nove chiavi indicate nell’issue. Leggi la sezione di AGENTS.md relativa a Heroku preboot, quindi esegui bundle exec rake db:migrate con una migrazione rename_column usa e getta. Il lavoro è completato quando compare la nota preboot senza modificare il testo degli altri messaggi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Follow-up from #2949 (preboot enabled on codebar-production).

With preboot, the release phase (rake db:prepare) runs before old web dynos stop, so old code serves against the new schema for ~3 minutes after each deploy. When strong_migrations raises on a destructive operation, its message ends with "wrap this step in a safety_assured block" — which under preboot only means "the old release tolerates this", not "this is safe to deploy right now". That distinction is documented in AGENTS.md ("Migrations and Heroku preboot") but is invisible at the moment a migration author is staring at the error.

Proposal

Append a short preboot note to the destructive-operation messages via StrongMigrations.error_messages (docs; key list in the gem's lib/strong_migrations/error_messages.rb, confirmed for 2.8.0). Relevant keys: change_column, change_column_with_not_null, change_column_default, change_column_null, rename_column, rename_table, rename_schema, rename_enum_value, execute. One possible shape:

# config/initializers/strong_migrations.rb
note = <<~TXT
  Heroku preboot: this runs in the release phase before old web dynos stop,
  so old code serves against the new schema for ~3 minutes after the deploy.
  See AGENTS.md ("Migrations and Heroku preboot"). If the migration cannot
  be made forward-compatible, disable preboot for this deploy.
TXT

%i[change_column change_column_with_not_null change_column_default
   change_column_null rename_column rename_table rename_schema
   rename_enum_value execute].each do |key|
  StrongMigrations.error_messages[key] = StrongMigrations.error_messages[key] + "\n\n" + note
end

Verification

Write a throwaway migration containing a flagged operation (e.g. rename_column), run bundle exec rake db:migrate in development, and check the printed message carries the note. Confirm no other message text changed.

Out of scope

Changing any gem defaults beyond messages; touching start_after or target_postgresql_version.

Lingua principale
Ruby
Stelle
104
Fork
205
Merge medio
1g 2h
PR unite (30g)
81

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di codebar/planner

Tutte le issue di codebar/planner

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.