Faraday: Changements de rupture pour Fastlane dans 0.16.2

Créé le 29 sept. 2019 · 15Commentaires · Source: lostisland/faraday

Informations de base

Version de Faraday : 0.16.2
Version rubis :
- Windows : ruby 2.4.6p354 (2019-04-01 révision 67394) [x64-mingw32]
- Mac : Ruby 2.5

Description du problème

Même avec faraday 0.16.2 et les correctifs de @BobbyMcWho , il y a des échecs de test pour 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 pour référence : https://github.com/fastlane/fastlane/pull/15407

Notez que nos tests n'échouent pas sur ruby 2.3 sur macOS et Ubuntu.

Source

janpio

Commentaire le plus utile

@janpio Je soupçonne que # 1039 devrait résoudre les problèmes avec les littéraux de chaîne gelés dans le corps.

BobbyMcWho le 30 sept. 2019

❤2

Tous les 15 commentaires

Cela devrait être corrigé par cette ligne dans fastlane/fastlane # 15403, je pense que c'est un effet secondaire d'un commentaire magique littéral de chaîne gelée quelque part

Edit : ~ qui ne peut pas être publié tant que lostisland/faraday_middleware#196 n'est pas approuvé et publié ~ Edit2 : il est rétrocompatible

BobbyMcWho le 29 sept. 2019

Oui, la voie à suivre est assez claire ici - et nous créerons une nouvelle version avec cela dès que possible.

Mais il y a des milliers d'installations Fastlane (et d'autres logiciels) cassées en ce moment, c'est pourquoi j'ai pensé qu'il était important de le signaler à nouveau explicitement.

Existe-t-il un moyen de faire fonctionner à nouveau cela dans une version 0.16.3 ?

janpio le 29 sept. 2019

Je ne suis pas à un endroit où je peux accéder à un ordinateur, mais d'un coup d'œil rapide en parcourant les fichiers sur mon téléphone, il me semble que quelque part à Faraday, nous définissons le corps de la requête sur une chaîne gelée. si nous pouvons trouver où ce corps de requête est défini sur une chaîne gelée, cela devrait résoudre le problème rapidement

BobbyMcWho le 29 sept. 2019

👍1

@janpio Je soupçonne que # 1039 devrait résoudre les problèmes avec les littéraux de chaîne gelés dans le corps.

BobbyMcWho le 30 sept. 2019

❤2

Merci d'être resté là pendant que les correctifs sont apparus. Merci BobbyMcWho pour la mise en œuvre !

Je suis curieux de savoir s'il y avait des chaînes de corps mutable _plus_ nécessaires dans d'autres adaptateurs ?

olleolleolle le 30 sept. 2019

J'ai jeté un coup d'œil au projet, rien d'autre ne me ressort immédiatement, la plupart des littéraux gelés sont des messages d'erreur ou sont utilisés d'une manière qui ne s'attendrait pas à ce qu'ils soient modifiables

BobbyMcWho le 1 oct. 2019

J'ai également vécu cela lors de l'utilisation de faraday 0.16.2 avec elasticsearch-transport (une dépendance de searchkick). Merci d'avoir mis un patch dans @BobbyMcWho !

zspencer le 3 oct. 2019

@zspencer , vous devrez peut-être pointer vers la branche 0.16.x de votre fichier gem si vous en avez besoin maintenant, jusqu'à ce que les responsables aient la possibilité de publier la version 0.16.3

BobbyMcWho le 3 oct. 2019

👍1

Merci! Je l'ai déjà fait. Je voulais m'assurer que les personnes qui rencontraient ce problème et ajoutaient des mots comme searchkick et elasticsearch à leurs requêtes google trouveraient le problème. (et la solution !)

zspencer le 5 oct. 2019

Bonjour à tous, nous sommes vraiment désolés pour toutes les perturbations causées par les versions v0.16.x.
Nous venons d'effectuer un ROLLBACK RELEASE v0.17.0 qui suit directement la dernière version de travail v0.15.4.
Veuillez mettre à jour cette version pour résoudre les problèmes de rétrocompatibilité.
Plus d'infos ici : https://github.com/lostisland/faraday/releases/tag/v0.17.0

iMacTia le 6 oct. 2019

Merci @iMacTia , cela s'appliquera-t-il également à faraday_middleware que nous avons jusqu'à présent conservé dans la même version que faraday ?

janpio le 7 oct. 2019

@janpio Je suis désolé, je ne suis pas sûr de comprendre. Ce problème ne devrait en aucun cas affecter faraday_middleware , car nous n'en avons publié aucune nouvelle version depuis février.
Je suis au courant de ce PR qui vise à ajouter la compatibilité avec la 0.16, mais qui ne sera plus publié.

Une fois que nous aurons publié Faraday v1.0, nous mettrons également à jour Faraday Middleware et publierons une v1.0 compatible.

S'il vous plaît laissez-moi savoir si vous demandiez autre chose 😄

iMacTia le 7 oct. 2019

Plus ou moins - dans notre gemspec, faraday_middleware était commenté avec in sync with faraday donc je me demandais s'il devait y avoir une version plus récente. Si ce n'est pas le cas, nous continuerons à en utiliser un plus ancien.

janpio le 7 oct. 2019

Faraday Middleware v0.13.1 fonctionnait bien avec Faraday v0.15.4, donc je m'attendrais à ce qu'il fonctionne aussi bien avec v0.17.0. Je vais déclencher une construction principale juste pour être sûr 👍

iMacTia le 8 oct. 2019

@janpio a déclenché https://travis-ci.org/lostisland/faraday_middleware/builds/595051325 , vous pouvez voir dans les journaux que Faraday v0.17.0 est utilisé et que tous les tests réussissent 🎉

iMacTia le 8 oct. 2019

❤1

Cette page vous a été utile?

0 / 5 - 0 notes