Faraday: Wichtige Änderungen für Fastlane in 0.16.2

Erstellt am 29. Sept. 2019 · 15Kommentare · Quelle: lostisland/faraday

Basisinformation

Faraday-Version: 0.16.2
Ruby-Version:
- Windows: ruby 2.4.6p354 (2019-04-01 Revision 67394) [x64-mingw32]
- Mac: Rubin 2.5

Fehlerbeschreibung

Auch bei Faraday 0.16.2 und den Fixes von @BobbyMcWho gibt es Testfehler für Fastlane:

Failures:
  1) Spaceship::Portal::Persons should change role
     Failure/Error: expect { person.change_role("member") }.to_not(raise_error)
       expected no Exception, got #<RuntimeError: can't modify frozen String> with backtrace:
         # ./spaceship/lib/spaceship/client.rb:811:in `force_encoding'
         # ./spaceship/lib/spaceship/client.rb:811:in `log_response'
         # ./spaceship/lib/spaceship/client.rb:846:in `block in send_request'
         # ./spaceship/lib/spaceship/client.rb:620:in `with_retry'
         # ./spaceship/lib/spaceship/client.rb:844:in `send_request'
         # ./spaceship/lib/spaceship/client.rb:688:in `request'
         # ./spaceship/lib/spaceship/portal/portal_client.rb:449:in `team_set_role'
         # ./spaceship/lib/spaceship/portal/person.rb:45:in `change_role'
         # ./spaceship/spec/portal/person_spec.rb:58:in `block (3 levels) in <top (required)>'
         # ./spaceship/spec/portal/person_spec.rb:58:in `block (2 levels) in <top (required)>'
     # ./spaceship/spec/portal/person_spec.rb:58:in `block (2 levels) in <top (required)>'
  2) Spaceship::Tunes::IAPList IAPList can delete
     Failure/Error: deleted = app.in_app_purchases.find("go.find.me").delete!
     RuntimeError:
       can't modify frozen String
     # ./spaceship/lib/spaceship/client.rb:811:in `force_encoding'
     # ./spaceship/lib/spaceship/client.rb:811:in `log_response'
     # ./spaceship/lib/spaceship/client.rb:846:in `block in send_request'
     # ./spaceship/lib/spaceship/client.rb:620:in `with_retry'
     # ./spaceship/lib/spaceship/client.rb:844:in `send_request'
     # ./spaceship/lib/spaceship/client.rb:688:in `request'
     # ./spaceship/lib/spaceship/tunes/tunes_client.rb:1235:in `delete_iap!'
     # ./spaceship/lib/spaceship/tunes/iap_list.rb:72:in `delete!'
     # ./spaceship/spec/tunes/iap_list_spec.rb:28:in `block (3 levels) in <top (required)>'
  3) Spaceship::Tunes::Members members creates a new member role: admin, apps: all
     Failure/Error: Spaceship::Members.create!(firstname: "Helmut", lastname: "Januschka", email_address: "[email protected]")
     RuntimeError:
       can't modify frozen String
     # ./spaceship/lib/spaceship/client.rb:811:in `force_encoding'
     # ./spaceship/lib/spaceship/client.rb:811:in `log_response'
     # ./spaceship/lib/spaceship/client.rb:846:in `block in send_request'
     # ./spaceship/lib/spaceship/client.rb:620:in `with_retry'
     # ./spaceship/lib/spaceship/client.rb:844:in `send_request'
     # ./spaceship/lib/spaceship/client.rb:688:in `request'
     # ./spaceship/lib/spaceship/tunes/tunes_client.rb:502:in `create_member!'
     # ./spaceship/lib/spaceship/tunes/members.rb:26:in `create!'
     # ./spaceship/spec/tunes/members_spec.rb:19:in `block (4 levels) in <top (required)>'

...

PR als Referenz: https://github.com/fastlane/fastlane/pull/15407

Beachten Sie, dass unsere Tests auf Ruby 2.3 auf macOS und Ubuntu nicht fehlschlagen.

Quelle

janpio

Hilfreichster Kommentar

@janpio Ich vermute, # 1039 sollte die Probleme mit eingefrorenen Zeichenfolgenliteralen im Körper beheben.

BobbyMcWho am 30. Sept. 2019

❤2

Alle 15 Kommentare

Dies sollte durch diese Zeile in fastlane/fastlane # 15403 behoben werden. Ich denke, es ist ein Nebeneffekt eines eingefrorenen String-Literal-Zauberkommentars irgendwo

Edit: ~das kann nicht veröffentlicht werden, bis lostisland/faraday_middleware#196 genehmigt und veröffentlicht ist~ Edit2: es ist abwärtskompatibel

BobbyMcWho am 29. Sept. 2019

Ja, der Weg nach vorne ist hier ziemlich klar - und wir werden damit so bald wie möglich eine neue Version schneiden.

Aber es gibt derzeit Tausende von Fastlane-Installationen (und anderer Software), die kaputt sind, weshalb ich es für wichtig hielt, dies noch einmal explizit zu melden.

Gibt es eine Möglichkeit, dies in einer 0.16.3 wieder zum Laufen zu bringen?

janpio am 29. Sept. 2019

Ich bin nicht an einem Ort, an dem ich an einen Computer gelangen kann, aber auf einen flüchtigen Blick beim Durchsuchen von Dateien auf meinem Telefon scheint es mir, dass wir irgendwo in Faraday den Anforderungstext auf eine eingefrorene Zeichenfolge setzen. Wenn wir herausfinden können, wo dieser Anforderungstext auf eine eingefrorene Zeichenfolge gesetzt wird, sollte das Problem auf der Überholspur behoben werden

BobbyMcWho am 29. Sept. 2019

👍1

@janpio Ich vermute, # 1039 sollte die Probleme mit eingefrorenen Zeichenfolgenliteralen im Körper beheben.

BobbyMcWho am 30. Sept. 2019

❤2

Danke, dass du durchgehalten hast, während die Fixes aufgetaucht sind. Danke BobbyMcWho für die Umsetzung!

Ich bin neugierig, ob in anderen Adaptern _mehr_ veränderliche Körperzeichenfolgen benötigt werden?

olleolleolle am 30. Sept. 2019

Ich habe das Projekt durchgesehen, nichts anderes fällt mir sofort auf, die meisten eingefrorenen Literale sind Fehlermeldungen oder werden auf eine Weise verwendet, die nicht erwarten würde, dass sie veränderbar sind

BobbyMcWho am 1. Okt. 2019

Ich habe dies auch erlebt, als ich Faraday 0.16.2 mit Elasticsearch-Transport (eine Abhängigkeit von Searchkick) verwendet habe. Vielen Dank für das Einfügen eines Patches in @BobbyMcWho!

zspencer am 3. Okt. 2019

@zspencer Sie müssen möglicherweise auf den 0.16.x-Zweig in Ihrer Gemfile zeigen, wenn Sie ihn gerade benötigen, bis die Betreuer die Möglichkeit haben, 0.16.3 zu veröffentlichen

BobbyMcWho am 3. Okt. 2019

👍1

Danke! Das habe ich bereits getan. Ich wollte sicherstellen, dass Leute, die auf dieses Problem stoßen und Wörter wie searchkick und elasticsearch zu ihren Google-Abfragen hinzufügen, das Problem finden würden. (und die Lösung!)

zspencer am 5. Okt. 2019

Hallo zusammen, es tut uns wirklich leid für all die Unterbrechungen, die durch die v0.16.x-Versionen verursacht wurden.
Wir haben gerade ein ROLLBACK RELEASE v0.17.0 durchgeführt, das direkt auf das neueste funktionierende Release v0.15.4 folgt.
Bitte aktualisieren Sie auf diese Version, um die Abwärtskompatibilitätsprobleme zu lösen.
Mehr Infos hier: https://github.com/lostisland/faraday/releases/tag/v0.17.0

iMacTia am 6. Okt. 2019

Danke @iMacTia , wird dies auch für faraday_middleware gelten, das wir bisher auf der gleichen Version wie faraday gehalten haben?

janpio am 7. Okt. 2019

@janpio Es tut mir leid, ich bin mir nicht sicher, ob ich es verstehe. Dieses Problem sollte faraday_middleware in keiner Weise betreffen, da wir seit Februar keine neue Version davon veröffentlicht haben.
Mir ist diese PR bekannt, die darauf abzielt, die Kompatibilität mit 0.16 hinzuzufügen, aber das wird nicht mehr veröffentlicht.

Sobald wir Faraday v1.0 veröffentlichen, werden wir auch Faraday Middleware aktualisieren und eine kompatible Version 1.0 veröffentlichen.

Bitte lassen Sie es mich wissen, wenn Sie nach etwas anderem gefragt haben 😄

iMacTia am 7. Okt. 2019

Mehr oder weniger - in unserer Edelsteinspezifikation wurde faraday_middleware mit in sync with faraday kommentiert, also habe ich mich gefragt, ob es tatsächlich eine neuere Version geben muss. Wenn das nicht der Fall ist, verwenden wir einfach ein älteres.

janpio am 7. Okt. 2019

Faraday Middleware v0.13.1 funktionierte gut mit Faraday v0.15.4, also würde ich erwarten, dass es auch mit v0.17.0 funktioniert. Ich werde jedoch einen Master-Build auslösen, nur um sicherzugehen 👍

iMacTia am 8. Okt. 2019

@janpio hat https://travis-ci.org/lostisland/faraday_middleware/builds/595051325 ausgelöst, Sie können in Protokollen sehen, dass Faraday v0.17.0 verwendet wird und alle Tests bestanden werden 🎉

iMacTia am 8. Okt. 2019

❤1

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen

Faraday: Wichtige Änderungen für Fastlane in 0.16.2

Basisinformation

Fehlerbeschreibung

Hilfreichster Kommentar

Alle 15 Kommentare

Verwandte Themen