[07:41:44]
<Thomas> > <@oniricorpe:im.emelyne.eu> I think it would be cool if there was a parameter for the "latest_commit" that allows the script not to make a PR if the last one is less than _n_ days old, to avoid PR spamming
Yes I agree! I have this "issue" for Terraforming-mars and soon™ for Overleaf. Update once a week would for example be good I think
[08:24:39]
<kayou> > <@oniricorpe:im.emelyne.eu> also, didn't someone once raise the number of ci runners to 3 or 5?
are you talking about the ci-apps runners?
[08:27:02]
<kayou> we can't really, because when all the ci-apps runners and ci-core runners are working at the same time, there are too many I/O on the harissa's SSD
[08:28:29]
<kayou> a solution is to add another server to the cluster (but i tried that a years ago and the cluster was not working properly, random errors etc)
[08:35:54]
<tituspijean> how much RAM has harissa? IIRC @selfhoster from last Yunocamp wanted to run his own CI with everything running on ramdisks
[08:37:32]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#1177197831](https://gitlab.com/yunohost/yunohost/-/pipelines/1177197831) failed on branch dev
[09:29:39]
<kayou> 16G
[09:29:40]
<kayou> i tried to do the same but it was not that easy (i don't remember why I gave up)
[09:53:32]
<tituspijean> Maybe 16GB would not be enough, especially if we run 3 workers at the same time. (some read https://brandonrozek.com/blog/lxdtmpfs/, might investigate someday^TM)
[09:53:39]
<Yunohost Git/Infra notifications> [yunohost] ✖️ Pipeline [#1177197831](https://gitlab.com/yunohost/yunohost/-/pipelines/1177197831) canceled on branch dev
[09:55:22]
<kayou> yep i followed this guide for the ramdisk on lxc
[09:55:58]
<Yunohost Git/Infra notifications> [yunohost] 🔴 Pipeline [#1177197831](https://gitlab.com/yunohost/yunohost/-/pipelines/1177197831) failed on branch dev
[09:57:11]
<kayou> all ci-core containers rebuilt
[09:57:17]
<kayou> ^
[10:26:58]
<Yunohost Git/Infra notifications> [issues] @tituspijean opened [issue #2332](https://github.com/YunoHost/issues/issues/2332): "Security" and threat model tutorial
[10:26:58]
<Yunohost Git/Infra notifications> [issues] @tituspijean labeled :book: documentation on [issue #2332](https://github.com/YunoHost/issues/issues/2332): "Security" and threat model tutorial
[10:28:17]
<tituspijean> (cf. the question in the support room)
[16:11:56]
<Yunohost Git/Infra notifications> [Applist builder error]
Failed to run the source auto-update for: anarchism, autobrr, galette, limesurvey, lstu, lufi, minetest, my_capsule, opensondage, osticket, owntracks, piped, pleroma, rss-bridge, tracim
Please run manually the `autoupdate_app_sources.py` script on these apps to debug what is happening!
See the debug log here: http://paste.yunohost.org/raw/igopiwirut"
[17:25:25]
<Salamandar> > <@yunohostinfra:matrix.org> [Applist builder error]
> Failed to run the source auto-update for: anarchism, autobrr, galette, limesurvey, lstu, lufi, minetest, my_capsule, opensondage, osticket, owntracks, piped, pleroma, rss-bridge, tracim
> Please run manually the `autoupdate_app_sources.py` script on these apps to debug what is happening!
> See the debug log here: http://paste.yunohost.org/raw/igopiwirut"
i think osticket failed because there was no `testing` branch
[17:25:29]
<Salamandar> that's fixed
[17:35:31]
<Salamandar> lstu failure reveals a bug i had already anticipated
[17:35:53]
<Salamandar> gitlab allows nested projects, so it's not owner/project anymore… it can be owner/project/project
[17:44:03]
<Salamandar> the issue is…
[17:44:04]
<Salamandar> https://docs.gitlab.com/ee/install/relative_url.html
[17:44:09]
<Salamandar> gitlab can be installed in a subpath
[17:44:47]
<Salamandar> so if you have code = https://mydomain.tld/subdir1/subdir2/project
[17:44:55]
<Salamandar> how can you decide it's gitlab = mydomain.tld/subdir, project = subdir2/project
[17:45:05]
<Salamandar> or gitlab = mydomain.tld, project = subdir1/subdir2/project
[17:45:09]
<Salamandar> gha
[17:49:38]
<Salamandar> well i guess i'll assume gitlab is installed on domain root…
[17:49:43]
<Salamandar> @Alekswag:matrix.org any idea ?
[17:50:10]
<Aleks (he/him/il/lui)> 😐️
[17:50:14]
<Aleks (he/him/il/lui)> burn computers
[17:52:22]
<Émy - OniriCorpe> > <@Salamandar:matrix.org> i think osticket failed because there was no `testing` branch
I saw a bunch of packagers who direct PR into master and the testing branch is updated by many years, while adding auto update x)
[17:52:48]
<eric_G> names?
[17:53:18]
<Émy - OniriCorpe> Didn’t noted x)
[17:53:29]
<Salamandar> > <@oniricorpe:im.emelyne.eu> I saw a bunch of packagers who direct PR into master and the testing branch is updated by many years, while adding auto update x)
i would love a bot that sees if testing can be fast-forwarded to master and rebases testing to master automagically
[17:53:39]
<Émy - OniriCorpe> I just rebased the testing branch
[17:53:46]
<eric_G> > <@oniricorpe:im.emelyne.eu> Didn’t noted x)
pitty
[17:54:26]
<Salamandar> > <@Salamandar:matrix.org> how can you decide it's gitlab = mydomain.tld/subdir, project = subdir2/project
i got some stupid heuristic by curl-ing the web page of the project, and grep-ing "/api/graphql", to find the root of the api…
[17:54:33]
<Émy - OniriCorpe> You can search for “rebase testing” in my latest PRs x)
[17:54:36]
<Salamandar> but i don't like it myself…
[17:59:56]
<Salamandar> > <@Salamandar:matrix.org> well i guess i'll assume gitlab is installed on domain root…
my own gitea is installed on a subpath…
[18:00:06]
<Salamandar> ><'
[18:18:02]
<Yunohost Git/Infra notifications> [yunohost] @Tagadda pushed 1 commit to Tagadda-patch-1: Update sury apt key ([707180da](https://github.com/YunoHost/yunohost/commit/707180da4363102766124aefc83c944672e880d3))
[18:20:22]
<Yunohost Git/Infra notifications> [yunohost] @Tagadda opened [pull request #1777](https://github.com/YunoHost/yunohost/pull/1777): Update sury apt key
[18:31:27]
<Salamandar> is it worth committing ?
[18:31:47]
<Salamandar> https://aria.im/_matrix/media/v1/download/matrix.org/hOCnHNAzvLPaDDadVGpsxggU
[18:44:35]
<Yunohost Git/Infra notifications> [yunohost] @alexAubin [commented](https://github.com/YunoHost/yunohost/pull/1777#discussion_r1492856661) on pull request #1777 Update sury apt key: suggestion # Purge expired keys (such as sury 95BD4743) EXPIRED_KEYS="(LC_ALL=en_US.UTF-8 apt-key list 2>/...
[20:33:12]
<Yunohost Git/Infra notifications> [Applist builder error]
Failed to run the source auto-update for: anarchism, autobrr, focalboard, limesurvey, lstu, lufi, minetest, opensondage, pleroma, rss-bridge, tracim
Please run manually the `autoupdate_app_sources.py` script on these apps to debug what is happening!
See the debug log here: http://paste.yunohost.org/raw/obibarunop"
[20:44:22]
<Émy - OniriCorpe> Awawa le ci est toujours bourré
[20:44:52]
<Salamandar> :D
[20:51:15]
<Émy - OniriCorpe> > <@yunohostinfra:matrix.org> [Applist builder error]
> Failed to run the source auto-update for: anarchism, autobrr, focalboard, limesurvey, lstu, lufi, minetest, opensondage, pleroma, rss-bridge, tracim
> Please run manually the `autoupdate_app_sources.py` script on these apps to debug what is happening!
> See the debug log here: http://paste.yunohost.org/raw/obibarunop"
Fixed autobrr
[20:52:31]
<Salamandar> merci, j'ai tenté de le fixer mais ça a pas été suffisant on dirait
[20:53:48]
<Émy - OniriCorpe> Ils sont relous ils ont changé le nom du fichier en random entre les releases
[20:54:03]
<Émy - OniriCorpe> Donc j’ai fait une condition “ou” dans la regex x)
[20:54:44]
<Salamandar> ><'
[20:54:46]
<Salamandar> j'ai une solution
[20:55:04]
<Salamandar> dans le manifest, on pourrait avoir resources.sources.*.autoupdate.version_regex
[20:55:34]
<Salamandar> ça permettrait de virer les `RuntimeError: No tags were found after sanity filtering!`
[20:55:43]
<Émy - OniriCorpe> `autoupdate.asset.armhf = "^autobrr_.*_linux_(arm|armv6).tar.gz$"`
[22:30:30]
<Yunohost Git/Infra notifications> @GitHangar forked SSOwat to [GitHangar/SSOwat](https://github.com/GitHangar/SSOwat)
[22:32:37]
<Yunohost Git/Infra notifications> @GitHangar forked yunohost-admin to [GitHangar/yunohost-admin](https://github.com/GitHangar/yunohost-admin)
[22:33:20]
<Yunohost Git/Infra notifications> @GitHangar forked yunohost to [GitHangar/yunohost](https://github.com/GitHangar/yunohost)
[23:00:16]
<Salamandar> https://github.com/YunoHost/apps/pull/2030/commits/e601d7a176ae016b44c627123611a7c2ca2d0a68
[23:01:34]
<Salamandar> https://aria.im/_matrix/media/v1/download/matrix.org/HbDKKbMdHgHCtXzAgIQSnUXu
[23:01:48]
<Émy - OniriCorpe> Part 8427
[23:01:57]
<Salamandar> hahaha
[23:02:05]
<Salamandar> yeah but this one actually is noice
[23:07:52]
<Salamandar> @oniricorpe:im.emelyne.eu comment appellerait-on la période pendant laquelle latest_github_tag ne trigger pas de nouvelle PR ?
[23:08:10]
<Salamandar> `no_spam_days` ?
[23:08:22]
<Salamandar> ou juste `minimum_days` ?
[23:09:20]
<Émy - OniriCorpe> “Delay”?
[23:10:09]
<Salamandar> mouais, ça donnerait l'impression que l'autoupdater va juste prévenir en retard
[23:10:11]
<Salamandar> hmmm
[23:10:19]
<Salamandar> quoiqu'en fait c'est ptêt ce qu'on veut en quelque sorte
[23:11:09]
<Salamandar> mais en fait je ne sais pas où j'irais piocher l'info de la dernière version poussée par le bot…
[23:11:15]
<Salamandar> bref dodo :D
[23:11:33]
<Émy - OniriCorpe> atermoiement
[23:11:52]
<Salamandar> > <@Salamandar:matrix.org> mais en fait je ne sais pas où j'irais piocher l'info de la dernière version poussée par le bot…
on n'a pas facilement l'info "la dernière date de ci-auto-update-pr"…
[23:12:02]
<Émy - OniriCorpe> Répit
[23:12:04]
<Salamandar> :D
[23:12:06]
<Salamandar> o/
[23:12:26]
<Émy - OniriCorpe> manoeuvre dilatoire
[23:12:36]
<Émy - OniriCorpe> Pardon je me suis juste perdue sur crisco
[23:13:25]
<Émy - OniriCorpe> > <@Salamandar:matrix.org> on n'a pas facilement l'info "la dernière date de ci-auto-update-pr"…
La date est dans le nom de version
[23:21:06]
<Salamandar> pas pour les autres…
[23:21:06]
<Salamandar> > <@oniricorpe:im.emelyne.eu> La date est dans le nom de version
pour la source main
[23:21:06]
<Salamandar> \><'
[23:22:30]
<Aleks (he/him/il/lui)> (j'ai suivi en diagonale mais perso je ferais pas un mécanisme de "ralentir la frequence de commit" seulement pour la stategy latest\_commit, mais pour tous les trucs, perso j'avais imaginé un truc genre `autoupdate.frequency = "evert N days"` et du coup faire juste un modulo sur l'id du jour en cours (genre de 0 à 365 bref)
[23:22:31]
<Aleks (he/him/il/lui)> (j'ai suivi en diagonale mais perso je ferais pas un mécanisme de "ralentir la frequence de commit" seulement pour la stategy latest\_commit, mais pour tous les trucs, perso j'avais imaginé un truc genre `autoupdate.frequency = "every N days"` et du coup faire juste un modulo sur l'id du jour en cours (genre de 0 à 365 bref)
[23:22:53]
<Aleks (he/him/il/lui)> (j'ai suivi en diagonale mais perso je ferais pas un mécanisme de "ralentir la frequence de commit" seulement pour la stategy latest\_commit, mais pour tous les trucs, perso j'avais imaginé un truc genre `autoupdate.frequency = "every N days"` et du coup faire juste un modulo sur l'id du jour en cours (genre de 0 à 365 bref) pour déterminer si il faut skip l'app ou non
[23:27:44]
<Salamandar> > faire juste un modulo sur l'id du jour
simple et efficace en effet
[23:28:06]
<Salamandar> bon sinon t'as une pr terminée à lire :p
[23:40:03]
<Aleks (he/him/il/lui)> merged ✅
[23:59:52]
<Salamandar> Merci ❤️