Repo2docker-action: MyBinder construit toujours l'image, plutôt que de la tirer

Merci d'avoir ouvert votre premier numéro dans ce projet ! Un tel engagement est essentiel pour les projets open source ! :câlins:

Si vous ne l'avez pas déjà fait, consultez le Code de conduite de Jupyter . Essayez également de suivre le modèle de problème car il aide les autres membres de la communauté à contribuer plus efficacement.

Vous pouvez rencontrer les autres Jovians en rejoignant notre forum Discourse . Il y a aussi un fil d'introduction où vous pouvez vous arrêter et dire bonjour! :vague:

Bienvenue dans la communauté Jupyter ! :tada:

Je sais que Binder utilise repo2docker, qui analysera votre référentiel à la recherche de fichiers de configuration ayant la priorité de construction suivante

En jetant un coup d'œil rapide à votre dépôt, il semble que vous ayez d'autres fichiers de construction qui signaleront à Binder de construire, plutôt que d'utiliser votre image. Je ne suis pas sûr qu'il existe un moyen de dire à Binder que vous souhaitez créer le Dockerfile en tant que première priorité. @choldgraf avez-vous des idées pour cela?

Oh mes excuses ont eu un léger malentendu.

On dirait que vous essayez de forcer MyBinder à créer une image pour le forcer à mettre l'image en cache. Veuillez garder à l'esprit que si votre dépôt contient des commits supplémentaires, le cache est invalidé. En outre, cela est soumis à la capacité et aux règles de mise en cache de MyBinder, qui peuvent changer au fil du temps.

Cela ne devrait pas du tout être lié au fait que votre image soit visible publiquement selon ma compréhension. J'ai tagué un ami qui a plus de perspicacité à ce sujet.

Si vous essayez simplement d'utiliser mybinder.org deux fois de suite pour démarrer un bloc-notes (sans vous fier à cette action), est-ce qu'il se construit à chaque fois ?

Oui - binder reconstruira l'image en fonction du hachage de validation, donc si vous modifiez le référentiel, une nouvelle version se déclenchera même si vous ne modifiez pas un fichier de configuration

Je vois. Je relance cette action à chaque commit. Donc, si j'attends que l'image Docker soit téléchargée avant de lancer le classeur, ne devrais-je pas voir un démarrage presque instantané ?

hmmm - donc l'action repo2docker crée simplement une image et la pousse vers un référentiel, elle ne fait rien spécifiquement avec Binder. Vous auriez besoin de configurer un référentiel Binder qui _extrait_ de l'endroit où repo2docker-action pousse, et de laisser ce statique afin que Binder ne le reconstruise pas à chaque fois.

Juste pour vérifier si j'ai bien compris votre dernier commentaire :

1. Je peux avoir une branche/dépôt séparé avec environment.yml et l'action poussant vers un référentiel de packages.
2. La branche principale a un binder/Dockerfile dont le seul contenu est la ligne FROM repo/package:latest .

@choldgraf @robertodr non, en fait, cette action a la possibilité de mettre en cache les builds directement sur MyBinder.org, cependant, si l'action finit par créer un commit pour vous, ce cache sera invalidé immédiatement.

Je vois que vous utilisiez le mauvais drapeau auparavant et que vous étiez censé utiliser MYBINDERORG_CACHE https://github.com/ENCCS/veloxchem-workshop/commit/eeb4832cd8f8de1400a0a8fe16b113675dd630b2#diff -3f922dcd4f5d4cc190cda19dceef3cf8f8bcda9dceef3c8

Est-ce que ça marche maintenant ?

Est-ce MYBINDERORG_CACHE ou BINDER_CACHE avec MYBINDERORG_TAG ? Il semble que cela fonctionne maintenant, mais c'est probablement parce que j'ai démarré les cahiers plusieurs fois de suite :facepalm:

@robertodr j'irais avec cet exemple du README, désolé signifiait TAG pas CACHE

@hamelsmu wow cette action est plus cool que dans mon souvenir 😄

Wow, oui, je me sens assez idiot maintenant... Je pense que j'ai essayé de faire en sorte que l'image soit transférée vers GHCR et je m'attendais à ce qu'elle soit utilisée automatiquement sur MyBinder.org. Ensuite, j'ai essayé de résoudre ce problème et j'ai mélangé les noms des options :facepalm:

Soit dit en passant, la tentative avec BINDER_CACHE a également fonctionné. Cependant, le référentiel spécifique avec lequel je travaille utilise LFS pour stocker les blocs-notes et ils ne seraient pas extraits correctement.

D'accord, super! Je clos ce sujet alors. C'était aussi un bon rappel pour moi car je n'avais pas regardé ce repo depuis un certain temps.