rebranding herald => steep

crates/devcontainer-rs/src/lib.rs

@@ -7,7 +7,7 @@
 //! l'intérieur du container en cours d'exécution.
 //!
 //! Le daemon est joint par son **socket** (celui de l'hôte, monté dans le
-//! container de Herald) : [`ContainerRuntime::connect`] suit `DOCKER_HOST` comme
+//! container de Steep) : [`ContainerRuntime::connect`] suit `DOCKER_HOST` comme
 //! le fait le CLI `docker`, et retombe sur le socket local. Aucun binaire de
 //! runtime n'est donc requis dans l'image, et `podman` fonctionne de la même
 //! façon dès lors qu'il expose son socket compatible Docker.

crates/devcontainer-rs/src/schema.rs

@@ -112,7 +112,7 @@ impl TryFrom<(DevContainerSchema, PathBuf)> for DevContainer {
 /// La spécification veut que `${localEnv:VAR}` soit lu dans l'environnement du
 /// client ; ici le `devcontainer.json` vient d'une **pull request**, donc de code
 /// non fiable : lire l'environnement du processus lui permettrait de récupérer
-/// `GITEA_TOKEN`, `OPEN_ROUTER_API_KEY` ou n'importe quel autre secret de Herald et
+/// `GITEA_TOKEN`, `OPEN_ROUTER_API_KEY` ou n'importe quel autre secret de Steep et
 /// de l'exfiltrer depuis un `build.args`, un `containerEnv`, son Dockerfile ou un
 /// hook. L'environnement n'est donc **jamais** consulté : seule la valeur par
 /// défaut est utilisée, et une référence sans défaut devient une chaîne vide.
@@ -272,7 +272,7 @@ mod tests {
         unsafe { std::env::set_var("DEVCONTAINER_TEST_SECRET", "s3cret") };
 
         // Le `devcontainer.json` vient d'une pull request : résoudre la référence
-        // depuis l'environnement de Herald y exposerait ses jetons.
+        // depuis l'environnement de Steep y exposerait ses jetons.
         assert_eq!(
             substitute_local_env("${localEnv:DEVCONTAINER_TEST_SECRET}"),
             ""