[06:59:47]
<tituspijean> Pas de soucis, prends soin de toi :)
Je laisse la main à oufmilo sur sa branche, et si c'est roule on écrasera tes premiers commits
[07:00:39]
<tituspijean> Pas de soucis, prends soin de toi :)
Je laisse la main à oufmilo sur sa branche, et si ça roule on écrasera tes premiers commits
[07:01:02]
<Tag> J'ai fais le tour de https://github.com/search?o=desc&q=org%3AYunoHost-Apps+%21testme&s=created&type=Issues et relancé les tests que le webhook n'a pas pu catch lors de la coupure
[07:01:15]
<Tag> aussi j'ai relancé deux tests (pour nextcloud et plateau) qui ont fail probablement à cause de la coupure
[10:27:34]
<Tag> #4619 ?
[11:08:43]
<Guillaume Bouzige> yup
[11:16:43]
<Guillaume Bouzige> 🤞
[11:49:53]
<Krakinou> Hi, I'm trying to set up autoupdater for the apps I maintain. My question is : how can I test the updater.sh script? Directly on my dev vm or should I push it on the github repo to test it there?
[11:50:36]
<Krakinou> also, should I set a updater.yml or does github took care of it?
[11:51:52]
<tituspijean> You need the .yml for the Github Action to run. If you want to test the .sh directly starting it should work, albeit with a bunch of warnings regarding the Github Actions environment
[11:53:16]
<Krakinou> ok thanks
[11:53:34]
<Krakinou> do you have a good repo example where I can have a look at how the yml is setp up?
[11:53:36]
<tituspijean> Best course would be :
1. Locally with `bash .github/workflows/updater.sh`
2. If satisfied with the result upload both .sh and .yml to the repo and try to run the action manually
[11:54:05]
<tituspijean> It should be a direct copy and paste of the yml.
[11:54:45]
<tituspijean> The only useful thing to tune in there is the cron frequency.
[11:56:26]
<Krakinou> I'm sorry : a copy and paste of which yml?
[11:56:52]
<tituspijean> Ah sorry xD
[11:57:07]
<tituspijean> In YunoHost/example_ynh for instance
[11:57:16]
<Krakinou> there is no yml there 🙂
[11:57:31]
<Krakinou> only updater.sh
[11:57:53]
<tituspijean> Dammit.
[11:58:01]
<tituspijean> Look into flarum_ynh
[11:58:19]
<tituspijean> *where* did I put the default yml...
[11:58:46]
<Krakinou> 😀
[11:58:59]
<Krakinou> ok thanks, I will try with that
[12:01:01]
<Krakinou> last question : will this sh/yml scripts run only on master, or on any branch?
[12:01:18]
<Krakinou> (so I can create a github branch to test it)
[12:21:32]
<tituspijean> It will run on the default branch by default. But you can change it temporarily to test it out ;)
[12:23:32]
<Tag> Je vais changer l'IP de ci-apps-dev pour une un peu mieux routée
[12:23:45]
<Tag> (on va éviter un allé-retour paris-bordeaux)
[12:24:59]
<Krakinou> c'est `base: testing` dans le yml?
[12:28:09]
<Tag> et voilà $ dig ci-apps-dev.yunohost.org
ci-apps-dev.yunohost.org. 150 IN A 46.231.241.32
[12:33:03]
<tituspijean> > <Krakinou> c'est `base: testing` dans le yml?
Ça ça veut dire que l'action va créer une nouvelle branche à partir de testing.
Par contre l'action prendra toujours le .yml de la branche par défaut pour le cron.
[12:33:38]
<tituspijean> (Et peut-être pour les déclenchements manuels aussi, j'avoue ne plus savoir)
[12:34:15]
<tituspijean> En parlant d'IP, quelqu'un récemment se plaignait que le forum ou la doc shaiplu n'était pas accessible en IPv6
[12:34:48]
<tituspijean> Je voulais regarder ça dans Samurai mais j'ai peur de tout péter
[12:40:30]
<Krakinou> @tituspijean : En fait, le yml peut être généré automatiquement par github quand on clique dans l'onglet "action", il y a un template yunohost à cet endroit
[12:40:51]
<Krakinou> par contre, il faudrait peut-être l'indiquer dnas le updater.sh pour les noobs comme moi
[12:41:48]
<tituspijean> Aaaaaah oui c'est vrai je l'avais mis en Action de l'organisation YunoHost-Apps
[12:44:11]
<Guillaume Bouzige> > <@tag:lostpod.me> #4619 ?
https://ci-apps-dev.yunohost.org/ci/job/4619 soon to be timeout...?
[12:45:55]
<Tag> Ah, it's fully stuck
[17:54:02]
<Krakinou> !!! Another analyseCI process is currently using the lock ./CI-2.lock !!!
[17:54:31]
<Krakinou> when I cancel a job on ci-apps-dev.yunohost.org, all new jobs get this error afterward
[17:55:19]
<Krakinou> for example, I canceled https://ci-apps-dev.yunohost.org/ci/job/4639 (because it was stuck), and all scheduled job afterwards failed miserably with this error
[19:44:34]
<Tag> /o\
[19:47:25]
<Tag> ok CI-2 is not locked anymore, I restarted the failed builds
[19:47:50]
<Krakinou> I noticed this happen each time I had canceled a test
[19:48:14]
<Krakinou> the lock is in fact not released
[19:48:55]
<Aleks (he/him/il/lui)> hmyeah that part of the code is a bit shaky if i remember correctly
[19:49:00]
<Aleks (he/him/il/lui)> i was surprised it worked before
[19:53:37]
<Krakinou> so maybe better to remove it totally?
[19:53:50]
<Krakinou> the "cancel job" button I mean
[20:24:22]
<Tag> Not sure that it's the "cancel" button only... I noticed this happen when a job is timed out after 180mins
[22:48:58]
<Krakinou> I don't know if it's only that, but I'm sure it happens each time 🙂