Protéger contre les commits relatifs à Rambo / architecture ARM/M1

[thbar]

Je viens de me faire avoir aussi je crée un ticket.

La librairie Rambo qu'on utilise pour lancer les processus externes fonctionne très bien, toutefois elle ne supporte pas officiellement l'architecture ARM (présente sur les "nouveaux" Mac M1, et je travaille la moitié du temps sur un MacBook Air M1).

Voir ici pour les usages de cette librairie.

Ça m'a amené à intégrer un pansement qui permet de travailler en local malgré tout sur Mac M1, avec de bons résultats:

transport-site/apps/transport/mix.exs

Lines 99 to 111 in 61eabf1

	# temporary fix until https://github.com/jayjun/rambo/pull/13 is merged
	# see https://github.com/etalab/transport-site/issues/2520.
	# Not perfect since this will impact `mix.lock`
	if apple_silicon?() do
	# branch is "aarch64-apple" but we're hardcoding the ref for security, especially since `mix.lock`
	# must not be committed in that case.
	# NOTE: this is not enough, and a manual `mix compile.rambo` must be issued manually in order
	# for this to work (https://github.com/jayjun/rambo/pull/13#issuecomment-1189194040).
	{:rambo, "~> 0.3.4",
	github: "myobie/rambo", ref: "e321db8e4f035f2a295ee2a5310dcb75034677ce"}
	else
	{:rambo, "~> 0.3.4"}
	end,

Le souci étant que cela modifie mix.lock au moment de mix deps.get.

Ce qui devait arriver à un moment arriva, j'ai commité une modification de mix.lock et ça a été déployé (voir #3813 (comment)).

Je vais aller corriger sur une PR spécifique, toutefois j'essayais également de protéger contre ce problème, et j'ai fait une tentative non complètement utilisable pour le moment que voici (dans build_test.exs):

test "rambo remains on hex version (not the ARM-compatible fork)" do
    {%{rambo: rambo}, []} = File.read!("../../mix.lock") |> Code.eval_string()
    # if this test fails, it may be because someone with a Mac M1 unintentionally committed `mix.lock` change
    # related to a Rambo-tweak, see https://github.com/etalab/transport-site/blob/61eabf185e71b7670e5d750048714636f85c5e58/apps/transport/mix.exs#L99-L111
    assert rambo |> elem(0) == :hex
  end

Je n'ai pas obtenu de failure sur le CI pour une raison que je devrai creuser, et par ailleurs j'ai des warnings qui me surprennent (que je remonterai au projet Elixir directement).

Bref je ne vais pas pouvoir protéger contre ça tout de suite, mais je conserve mes notes ici 😄

Il faut noter par ailleurs que l'usage de Rambo est satisfaisant, on n'a pas eu de souci type processus zombies ou autre depuis sa mise en place, et que donc ce souci précis ne me semble pas nécessiter une bascule vers autre chose à ce stade (même si on peut remarque une absence de commits depuis 2 ans, qu'il faudra suivre !).

[thbar]

Mon test en CI montre que le CI modifie mix.lock, c'est pour cela que la détection que j'avais tenté ne fonctionne pas.

Je contourne avec une commande qui demandera l'état dans git.

[thbar]

Traité dans:

• Mise à jour librairie de gestion des timezones (tzdata) #4177