Faraday: Cambios importantes para fastlane en 0.16.2

Creado en 29 sept. 2019 · 15Comentarios · Fuente: lostisland/faraday

Información básica

Versión Faraday: 0.16.2
Versión rubí:
- Windows: ruby 2.4.6p354 (2019-04-01 revisión 67394) [x64-mingw32]
- Mac: Rubí 2.5

Descripcion del problema

Incluso con faraday 0.16.2 y las correcciones de @BobbyMcWho , hay fallas en las pruebas para 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 para referencia: https://github.com/fastlane/fastlane/pull/15407

Tenga en cuenta que nuestras pruebas no están fallando en Ruby 2.3 en macOS y Ubuntu.

Fuente

janpio

Comentario más útil

@janpio Sospecho que el n.º 1039 debería solucionar los problemas con los literales de cadena congelados en el cuerpo.

BobbyMcWho en 30 sept. 2019

❤2

Todos 15 comentarios

Esto debería arreglarse con esta línea en fastlane/fastlane#15403, creo que es un efecto secundario de un comentario mágico literal de cadena congelada en alguna parte

Edición: ~que no se puede publicar hasta que se apruebe y publique lostisland/faraday_middleware#196~ Edición 2: es compatible con versiones anteriores

BobbyMcWho en 29 sept. 2019

Sí, el camino a seguir es bastante claro aquí, y lanzaremos una nueva versión tan pronto como sea posible.

Pero hay miles de instalaciones de Fastlane (y otro software) rotas en este momento, por lo que pensé que era importante informar esto explícitamente nuevamente.

¿Hay alguna manera de hacer que esto funcione nuevamente en 0.16.3?

janpio en 29 sept. 2019

No estoy en un lugar donde pueda acceder a una computadora, pero de un vistazo superficial al navegar por los archivos en mi teléfono me parece que en algún lugar de Faraday estamos configurando el cuerpo de la solicitud en una cadena congelada. si podemos encontrar dónde se establece el cuerpo de la solicitud en una cadena congelada, eso debería solucionar el problema en el carril rápido

BobbyMcWho en 29 sept. 2019

👍1

@janpio Sospecho que el n.º 1039 debería solucionar los problemas con los literales de cadena congelados en el cuerpo.

BobbyMcWho en 30 sept. 2019

❤2

Gracias por aguantar mientras aparecían las correcciones. ¡Gracias BobbyMcWho por implementar!

Tengo curiosidad por saber si se necesitaban _más_ cadenas de cuerpo mutables en otros adaptadores.

olleolleolle en 30 sept. 2019

Eché un vistazo al proyecto, nada más me llama la atención de inmediato, la mayoría de los literales congelados son mensajes de error o se están utilizando de maneras que no esperarían que fueran mutables.

BobbyMcWho en 1 oct. 2019

También experimenté esto cuando usé faraday 0.16.2 con elasticsearch-transport (una dependencia de searchkick). ¡Gracias por poner un parche en @BobbyMcWho!

zspencer en 3 oct. 2019

@zspencer , es posible que deba señalar la rama 0.16.x en su archivo gem si la necesita en este momento, hasta que los mantenedores tengan la oportunidad de lanzar 0.16.3

BobbyMcWho en 3 oct. 2019

👍1

¡Gracias! Ya lo he hecho. Quería asegurarme de que las personas que se encontraban con este problema y agregaban palabras como searchkick y elasticsearch a sus consultas de Google encontrarían el problema. (¡y la solución!)

zspencer en 5 oct. 2019

Hola a todos, lamentamos mucho las interrupciones causadas por los lanzamientos de v0.16.x.
Acabamos de realizar una ROLLBACK RELEASE v0.17.0 que sigue directamente a la última versión de trabajo v0.15.4.
Actualice a esa versión para resolver los problemas de compatibilidad con versiones anteriores.
Más información aquí: https://github.com/lostisland/faraday/releases/tag/v0.17.0

iMacTia en 6 oct. 2019

Gracias @iMacTia , ¿esto también se aplicará a faraday_middleware que hasta ahora mantuvimos en la misma versión que faraday ?

janpio en 7 oct. 2019

@janpio Lo siento, no estoy seguro de entender. Este problema no debería afectar a faraday_middleware de ninguna manera, ya que no lanzamos ninguna versión nueva desde febrero.
Soy consciente de este PR que tiene como objetivo agregar compatibilidad con 0.16, pero eso ya no se lanzará.

Una vez que lancemos Faraday v1.0, también actualizaremos Faraday Middleware y lanzaremos una v1.0 compatible.

Por favor, avíseme si estaba preguntando sobre algo más 😄

iMacTia en 7 oct. 2019

Más o menos: en nuestra especificación de gemas faraday_middleware se comentó con in sync with faraday por lo que me preguntaba si realmente es necesario que haya una versión más nueva. Si ese no es el caso, simplemente seguiremos usando uno más antiguo.

janpio en 7 oct. 2019

Faraday Middleware v0.13.1 funcionaba bien con Faraday v0.15.4, por lo que esperaba que funcionara también con v0.17.0. Sin embargo, activaré una compilación maestra solo para estar seguro 👍

iMacTia en 8 oct. 2019

@janpio activó https://travis-ci.org/lostisland/faraday_middleware/builds/595051325 , puede ver en los registros que se usa Faraday v0.17.0 y todas las pruebas están pasando 🎉

iMacTia en 8 oct. 2019

❤1

¿Fue útil esta página

0 / 5 - 0 calificaciones