#dusk $DUSK @Dusk .....Je ne cherchais pas une mise à jour de Dusk concernant les Mac.
Je fouillais Piecrust, et une toute petite modification du CI m’a fait m’arrêter.
@dusk a déplacé la validation ARM de macOS hors du workflow principal et dans un chemin distinct, filtré par des conditions....
Au début, ça ressemble à une simple routine d’ingénierie sans intérêt.
Puis je me suis rappelé ce qu’est réellement Piecrust.
C’est la machine virtuelle WASM située sous les smart contracts de Dusk. Donc la vraie question devient : comment tester une couche d’exécution critique sans laisser chaque cas limite spécifique à une plateforme ralentir tout le pipeline de développement ?
Imaginez inspecter un avion...
Les contrôles standards se font à chaque fois.
Une configuration spéciale obtient sa propre procédure de test lorsque le matériel l’exige...
C’est fondamentalement ce que fait ce changement.
Le pipeline régulier reste focalisé sur la validation de base, tandis que les tests de macOS ARM peuvent tourner séparément sur des déclencheurs précis, au lieu de devenir un chemin obligatoire pour tout..
Et cette distinction compte encore plus à mesure que le protocole évolue.
Le travail de Rusk en 1.7.x a déjà commencé à toucher au comportement de la VM autour du hardfork de Boréas, y compris des changements liés à des événements annulés et à la façon dont la rejoue historique se comporte. Piecrust fait clairement encore partie d’une pile d’exécution en évolution constante.
Ce qui m’intéresse n’est pas « Dusk prend en charge une autre machine ».
C’est le compromis d’ingénierie...
Vous pouvez exécuter tous les tests partout, à chaque fois.
Ou vous pouvez garder le chemin critique bien serré et isoler la validation spécifique à la plateforme là où elle apporte vraiment un signal..
Aucune des deux approches n’est automatiquement meilleure.
Mais pour une VM de smart contract, je préfère organiser les tests autour des zones où le risque d’exécution existe, plutôt que autour d’une énorme checklist.
C’est la partie invisible des infrastructures que les gens remarquent rarement.
La qualité d’une blockchain ne dépend pas seulement de ce qui atteint le mainnet.
Elle dépend aussi de la façon dont le logiciel en dessous est mis à l’épreuve avec soin avant d’y arriver.
Donc, que voudriez-vous optimiser en premier ?
Plus de tests à chaque changement, ou plus de tests ciblés pour les chemins d’exécution les plus susceptibles d’échouer ?
$ACE $TRUMP
Je fouillais Piecrust, et une toute petite modification du CI m’a fait m’arrêter.
@dusk a déplacé la validation ARM de macOS hors du workflow principal et dans un chemin distinct, filtré par des conditions....
Au début, ça ressemble à une simple routine d’ingénierie sans intérêt.
Puis je me suis rappelé ce qu’est réellement Piecrust.
C’est la machine virtuelle WASM située sous les smart contracts de Dusk. Donc la vraie question devient : comment tester une couche d’exécution critique sans laisser chaque cas limite spécifique à une plateforme ralentir tout le pipeline de développement ?
Imaginez inspecter un avion...
Les contrôles standards se font à chaque fois.
Une configuration spéciale obtient sa propre procédure de test lorsque le matériel l’exige...
C’est fondamentalement ce que fait ce changement.
Le pipeline régulier reste focalisé sur la validation de base, tandis que les tests de macOS ARM peuvent tourner séparément sur des déclencheurs précis, au lieu de devenir un chemin obligatoire pour tout..
Et cette distinction compte encore plus à mesure que le protocole évolue.
Le travail de Rusk en 1.7.x a déjà commencé à toucher au comportement de la VM autour du hardfork de Boréas, y compris des changements liés à des événements annulés et à la façon dont la rejoue historique se comporte. Piecrust fait clairement encore partie d’une pile d’exécution en évolution constante.
Ce qui m’intéresse n’est pas « Dusk prend en charge une autre machine ».
C’est le compromis d’ingénierie...
Vous pouvez exécuter tous les tests partout, à chaque fois.
Ou vous pouvez garder le chemin critique bien serré et isoler la validation spécifique à la plateforme là où elle apporte vraiment un signal..
Aucune des deux approches n’est automatiquement meilleure.
Mais pour une VM de smart contract, je préfère organiser les tests autour des zones où le risque d’exécution existe, plutôt que autour d’une énorme checklist.
C’est la partie invisible des infrastructures que les gens remarquent rarement.
La qualité d’une blockchain ne dépend pas seulement de ce qui atteint le mainnet.
Elle dépend aussi de la façon dont le logiciel en dessous est mis à l’épreuve avec soin avant d’y arriver.
Donc, que voudriez-vous optimiser en premier ?
Plus de tests à chaque changement, ou plus de tests ciblés pour les chemins d’exécution les plus susceptibles d’échouer ?
$ACE $TRUMP