Official topic for apps group news


#41

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.


#42

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.


#43

OK. I’m convinced :wink: Let’s go for these two tags.


#44

Just writing here what I told to @Maniack_Crudelis directly: I agree with that proposal :wink:


#45

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.


#46

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.


#47

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.


#48

Pi rebooted yesterday evening ! It becomes unreachable quite often even from LAN nework :confused:


#49

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.