I don’t understand the difference between the two here (high quality and featured). I’m thinking that we will really be lost. One tag is for me enough. We are not a so big community to have level + tags… well it’s only my point of view.
For the rest it’s ok.
That’s all the point of the meeting we had !
The tag high_quality represent the level 8, for very good apps. That’s simply a way to replace Official apps.
The tag featured is for high_quality apps we would like to highlight for a moment. Like we would do with an app like Nextcloud or Mattermost.
That 2 different things but not that much work. There’s nothing special to do about Featured apps. The only thing will be to define a way to choose them. It was discuss of a poll, which looks like a good idea to me. There’s other things to define about it.
There’s 2 tags because there’s 2 different things we would like to do.
Give a special status to very well maintained apps. Because packagers are spending a lot of time doing it. And at least, for them we can says to the community that there’s quite safe.
And, highlight apps that are really wanted by the community. That’s 2 different purposes.
OK. I’m convinced 
Let’s go for these two tags.
Paving the way for the new ongoing CI ci-apps-hq, I worked on the way the CI dev is getting automatically the jobs.
Initially it was getting jobs from the branches on official apps.
But since, we’ve decided to turn official apps into high quality, we should expect more and more of those. Or at least I hope !
Nowadays, we have a strong limitation with external pull request, PR made on forked repositories and trying to be merged in the official repo. Because those PR aren’t on local branches.
Each time, one of us (me…) have to connect to the server to add it manually, so we can have a test from the CI on those PR.
We can’t expect that manual action with high quality apps, considering we would have a lot more of them.
So now the CI dev is getting its jobs from the github API, for each PR, not regarding anymore the branches themselves.
The big changes about that are:
The idea behind is first to not mixed PR from their branches, we could have many PR from testing from forked repositories. But you can’t have many time the same PR.
Second to simplify the naming of links in the PR, It would be simply the ID of the PR, and the same for each PR.
Also, we have, for example for nextcloud, a jobs https://ci-apps-dev.yunohost.org/jenkins/job/nextcloud_ynh%20PR174/, which is for https://github.com/YunoHost-Apps/nextcloud_ynh/pull/174. A PR from a forked repo. Without having to add it manually.
While I’m building a new ci-apps-arm server, I update fingerprints for all raspi.
@rafi59, your raspi is unreachable on pcheck@rafi59.codelib.re -p 2244.
Same for you @jibecfed on pcheck@holcroft.fr -p 10777.
And @Gofannon on pcheck@gofannon.ynh.fr -p 62022.
I moved ci-apps-arm to a new server on a scaleway VPS.
Because that way, it just works !!!
Maybe it will need a few hour for the dns to be updated.
Pi rebooted yesterday evening ! It becomes unreachable quite often even from LAN nework 
Thanks Gofannon, it works again.
Do you have any idea why it becomes unreachable ?
I have to admit mine too sometimes, but as I use it as a kodi media server, I notice when it happens.
No idea and I didn’t investigate. The pi is dedicated and behind the ISP box so I know it failed when I try to connect to it to do some upgrades.
I thought that it was because of my unusual network setup. Sometimes, it becomes unreachable a few minutes after rebooted it Since yesterday, it’s still there so wait and see
Hello there,
if it can be from any use, I have an unused raspberry pi (Pi1, model B rev2) along with a SSD HD (more stable) waiting on a shelf at home.
I initially planned to use it as a backup but as I found another solution, I would be glad to set it up to help the project.
Let me know if this is of any interest to you.
I don’t know if a Pi1 can run apps like a Pi3 without dying under the load.
But if it can, yep all Raspi are welcome 
Well, sure…
We can give it a try if you want, just tell me what to do
First thing is to run that script https://github.com/YunoHost/CI_package_check/blob/master/auto_build/chroot_ssh.sh.
Then, to add your raspi to the pool on the CI itself.
I’ll restore the configuration of my Raspberry Pi so you can use it for CI. I’ll ping pack here in the coming days.
Some news about our CI,
A new CI is now online, ci-apps-hq.
This CI is design to automatically test all pull requests for High Quality apps (Official apps as well).
This new CI is doing those tests in replacement of ci-apps-dev which is now only working on apps from packagers.
I made this change because I hope we would expect more tests on ci-apps-dev, with the new documentation about it. And, at the same time, more High Quality apps that we already have Official ones.
So those CI will be less overloaded.
I’ve merged the PR to move to apps.py on yunorunner, this is going to be deployed once the app will be updated (I’ve also fixed 2 security vulnerabilities in dependencies).
That’s old news now but after hours and hours I’ve finally managed to fix the memory leaks of yunorunner x_x
Hi guys,
I just moved ci-apps-arm.yunohost.org to a new scaleway server, with 2Go of ram instead of 1. Because it was constantly failing because of lack of ram…
Hope it will be better now…
Thank you!
Hi guys
I moved ci-apps-hq to the testing branch of package check, mostly because we have an issue with gitlab (not yet fixed though…) and also because there’s a lot of new stuff that would be nice to try before releasing into the official CI.
Current changes of this testing are