Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
thbar opened this issue Mar 19, 2024 · 2 comments
Closed

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

thbar opened this issue Mar 19, 2024 · 2 comments
Labels
dette technique Entretien & maintenance générale, nécessaire pour que le code reste de bonne qualité

Comments

@thbar
Copy link
Contributor

thbar commented Mar 19, 2024

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:

# 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 thbar added the dette technique Entretien & maintenance générale, nécessaire pour que le code reste de bonne qualité label Mar 19, 2024
thbar added a commit that referenced this issue Sep 12, 2024
It will catch the issue at least locally. But CI must likely be fixed to detect it.
@thbar
Copy link
Contributor Author

thbar commented Sep 12, 2024

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 added a commit that referenced this issue Sep 12, 2024
@thbar
Copy link
Contributor Author

thbar commented Sep 12, 2024

@thbar thbar closed this as completed Sep 12, 2024
thbar added a commit that referenced this issue Sep 12, 2024
Co-authored-by: Antoine Augusti <antoine.augusti@transport.data.gouv.fr>
github-merge-queue bot pushed a commit that referenced this issue Sep 17, 2024
* Bump tzdata

See: lau/tzdata#148

* Remove left-over :focus tags

* Re-introduce test for #3820

It will catch the issue at least locally. But CI must likely be fixed to detect it.

* Add temporary printf debugging (TM) to try to figure out the lack of failure on CI

* Verify the destiny of the lock file (likely modified)

* Implement a CI-reproduction for #3820

* Fix regression (#3820)

Co-authored-by: Antoine Augusti <antoine.augusti@transport.data.gouv.fr>

---------

Co-authored-by: Antoine Augusti <antoine.augusti@transport.data.gouv.fr>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dette technique Entretien & maintenance générale, nécessaire pour que le code reste de bonne qualité
Projects
None yet
Development

No branches or pull requests

1 participant