j’aimerais publier ce message, mais l’étape de release ne veut pas se déclencher, je comprends pas pourquoi, ça me saoule, j’aime pas la CI gitlab (et je reconnais que je mets de la mauvaise volonté) https://git.duniter.org/clients/rust/gcli-v2s/-/pipelines/43220
La version 0.5.0 de gcli permet de se connecter à la gtest dans son état actuel avec le nouveau runtime, l’utilisation de la runtime api pour la récupération du solde (donc inclut les DU non réclamés), met à jour subxt, et ajoute la compatibilité avec squid 0.5.0 (postgraphile) (et casse squid <0.5.0 hasura). Le build macos est désactivé en attendant que quelqu’un le répare.
mais là tu as juste le job MacOS qui plante, tu peux le désactiver pour le moment?
cc @Nicolas80 je te vois bosser dessus en même temps que moi, je tente juste un truc sur une branche alternative.
Faut pousser un tag pour trigger ta CI, on peut supprimer le tag après.
@poka Hehe, je viens de voir que tu tente de corriger le build macos aussi
J’avoue que je connais pas trop, mais a priori, vu l’erreur que l’on avait eue dans la pipeline “_SecTrustEvaluateWithError” il semblerait que l’on doive sans doute utiliser macos 10.14 ou plus (au lieu de 10.12)…
Les changements que j’ai fais sont avec l’IA; mais effectivement, on peut tester un build - j’ai fais une version spécifique pour - 0.5.0-macosfix-RC1
D’ailleurs, c’est pas très clair, mais le Dockerfile.ci qui est dans le repo, c’est bien celui qui te sert à créer l’image poka/rust-osxcross:latest ?
Changement fait dans la branche macos_ci_fix_trial_0.5.0 si tu veux regarder.
Je viens d’ajouter un tag, on va voir ce que cela donne.
Si tu as mieux ou plus clean (tu connais probablement bien mieux que moi gitlab CI), on peut juste supprimer ma branche
Pour le moment, l’image est avec mon user Docker; si ça fonctionne, il faudrait la refaire au propre j’imagine ?
Je suppose que cela devrais être possible de la faire générer par gitlab ci et avec des credentials docker de notre gitlab (s’il en a ?)
error[E0463]: can't find crate for `core`
|
= note: the `x86_64-apple-darwin` target may not be installed
= help: consider downloading the target with `rustup target add x86_64-apple-darwin`
For more information about this error, try `rustc --explain E0463`.
error: could not compile `cfg-if` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `bytes` (lib) due to 1 previous error
error: could not compile `const-oid` (lib) due to 1 previous error
error: could not compile `subtle` (lib) due to 1 previous error
error: could not compile `smallvec` (lib) due to 1 previous error
error[E0463]: can't find crate for `std`
|
= note: the `x86_64-apple-darwin` target may not be installed
= help: consider downloading the target with `rustup target add x86_64-apple-darwin`
error: could not compile `log` (lib) due to 1 previous error
error: could not compile `pin-project-lite` (lib) due to 1 previous error
Cleaning up project directory and file based variables
00:01
ERROR: Job failed: exit code 1
J’arrête la pour aujourd’hui; j’espère que tu vas trouver
Pour l’affichage des adresses (liées au préfix), je vais regarder dans les jours qui viennent - il faut aussi revoir la persistance du vault - j’utilise l’adresse ss58 comme clé primaire, mais on devrait utiliser l’adresse publique qui ne change pas à la place…
Ha je vois que tu avais lancé ça mais ça à planté sur la dernière partie qui n’existait pas avant generate_homebrew_formula
$ SHA256=$(shasum -a 256 gcli.tar.gz | awk '{ print $1 }')
/bin/sh: eval: line 187: shasum: not found
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: exit code 127
J’ai pu récupérer la clé en local depuis gitlab; et j’ai fais des tests, elle est en fait correcte si on ajoute un dernier retour à la ligne après le footer.
Pour tester la clé, la commande qui fournit la clé publique (erreur si le format de la clé privée est incorrect)
ssh-keygen -y -f homebrew.key
J’ai ajouté ce retour à la ligne supplémentaire dans gitlab également.
Je continuerai à regarder ce soir, mais il faudra peut-être adapter aussi le script pour être sur qu’il garde bien exactement le bon format quand il remet cela dans un fichier .key.
D’après mes tests en local, l’utilisation de echo ne garde pas les retours à la ligne (avec ou sans l’argument “-e”).
Par contre, une commande du genre printf '%s' "$TEST_KEY" semble bien les garder.
Hum… je dois encore confirmer avec le prochain build ou j’ai ajouté du débug sur une nouvelle variable de test $TEST_KEY, mais on dirait que lorsque l’on spécifie le type “file” pour une variable ci/cd; cela nous donne un path vers le fichier qui contient le contenu; et pas le contenu lui même
Project, group, and instance CI/CD variables are “variable” type by default, but can optionally be set as a “file” type (“variable_type”: “file” in the API). File type variables:
Consist of a key, value, and file.
Are made available in jobs as environment variables, with:
The CI/CD variable key as the environment variable name.
The CI/CD variable value saved to a temporary file.
The path to the temporary file as the environment variable value.
Par contre, le contenu est totalement vide (juste un retour de ligne qui est ajouté par le printf) ???
$ printf '%s\n' "$TEST_KEY" > ~/.ssh/id_rsa_test
$ echo "HexDump of the test key file for debugging purposes:"
HexDump of the test key file for debugging purposes:
$ hexdump -C ~/.ssh/id_rsa_test
00000000 0a |.|
00000001
$ echo "Output sha256sum of the test key file for debugging purposes:"
Output sha256sum of the test key file for debugging purposes:
$ sha256sum ~/.ssh/id_rsa_test
01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b /root/.ssh/id_rsa_test
Je me demande si c’est pas du au setting “protected”’
Et j’ai trouvé la doc pour GitLab qui parle des variables protégées:
@poka, @HugoTrentesaux vous pensez que je peux retirer le “protected” pour la clé Homebrew dans les variables CI/CD ?
Car sinon il faudrait à priori autoriser l’usage pour les merge request, mais il faut également que les branches source et destination soient protégées…
Et je pense qu’en général, la branche source est rarement protégée…
Un développeur (rôle GitLab) du projet pourrait accéder au contenu de la variable en créant une branche dans laquelle il y a un echo $VARIABLE dans le .gitlab-ci.yml.
Cette variable devrait être utilisée uniquement lors d’une release déclenché par un tag git (protégé) ou une branche protégée, à moins que le workflow du projet soit différent.
Ok, mais du coup, est-ce que tu sais me dire comment cela fonctionne pour créer un tag “protégé” quand on fait nos tests (sans MergeRequest derrière) ?
Et deuxième question; lorsque l’on fait une merge request depuis une branche que l’on a nous-même créée (et non protégée je suppose) est-ce que cela devrait fonctionner ? (je suppose que cela pourrait fonctionner gràce au tag que l’on réalise après également ?)
Tu peux protéger tes tags et branches temporairement pour tes tests.
Sinon, tu peux également déprotéger temporairement ta variable CI/CD le temps de tes tests.
J’avoue que je ne suis pas sur du workflow de release actuel
Je ne sais plus trop qu’est-ce qui est lancé automatiquement lors du merge d’une MergeRequest…
Quelle serait la meilleure configuration pour que cela soit cohérent ?
Est-ce que pour une release on préfère que ce soit un Maintainer qui crée un tag protected et du coup c’est en dehors du mécanisme des MergeRequests… ?
