Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Add preboot context to strong_migrations destructive-operation messages

Offen Anfängerfreundlich
#2,963 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
76/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
ruby
Bereich
databases, devops

Rechercherichtung

Beginne mit config/initializers/strong_migrations.rb und der strong_migrations-Schlüsselliste in lib/strong_migrations/error_messages.rb und konzentriere dich auf die neun im Issue genannten Schlüssel. Lies den Abschnitt in AGENTS.md zu Heroku preboot und führe anschließend bundle exec rake db:migrate mit einer Wegwerf-rename_column-Migration aus. Als abgeschlossen gilt die Aufgabe, wenn der preboot-Hinweis erscheint, ohne anderen Nachrichtentext zu ändern.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Ruby
Sterne
104
Forks
205
Ø Merge
1 T. 4 Std.
Gemergte PRs (30 T.)
77

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus codebar/planner

Alle Issues in codebar/planner

Ähnliche Issues

Weitere Issues zu Ruby

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.