I open this new topic to have a way to share information regarding all members of @Apps group (and everyone who want to follow it)
So, let’s start with some news for the Apps group.
@kanhu is now part of the group, a big welcome to him
And other news, the CI unstable is stopped since yesterday, the server hosting both the CI unstable and ARM, samourai, does not have enough memory, so we had a lot of problem, especially with slapd crashing regularly. But without slapd, no sudo, and without sudo, a lot of command don’t work…
So I decided to stop unstable and keep ARM. Because this CI is not using a lot of memory since it doesn’t have package check or any lxc running inside.
We currently have ci-apps, the “official” CI on a scaleway, because of the issues we had with jenkins.
This CI will go back to its original container on bearnaise, and the scaleway will then be used to host the unstable CI instead.
- ppr has proposed a Raspberry Pi for our ARM CI. Thanks to him.
- I’ve changed the dns for ci-apps, now it points to bearnaise with the former container. While unstable is on scaleway, but the CI isn’t working yet for the second one.
- ci-apps is already running on bearnaise, even if the dns is not yet propagated… And I’m waiting to know if the level will be announce on xmpp.
- ci-arm is back on business, I’ve stopped the unstable container. And restarted the ARM one.
samourai seems happy now.
Again, some news \o/
- As you’ve probably already seen, ci-apps is back on xmpp
- Our kanboard is back
- And, because it’s sometime difficult to handle dns with package check, I’ve coded a small piece of code to fix it automatically during the build script.
I’ve deployed a new patch for YunoRunner to make it a bit more efficiant: it does jobs merging.
The main idea is to only have at most one scheduled job per app because this job will pull the latest commits anyway. This avoid a situation where someone push 10 times in one hour which would schedule 10 jobs for the same app which would be useless and takes the place of others jobs.
If there is a doubt on if the jobs were correctly merged, the logs should be very explicit about that.
I couldn’t deploy it on ci-unstable since the lxc was stopped.
Hello @Maniack_Crudelis, I cannot access to the kanban. I get the Yunohost SSO splashscreen. Is it supposed to be public ?
I can’t access to this too
The deployment was done this weekend after a script’s update.
I hope it works on your side.
I’m OK for making it public, but to create a dedicated account for every user (beware of spam…).
Yep, anyway, only members of Apps group should have a real account on it.
But, if we can have a public read-only access, it could be interesting for those who want to contribute.
I’m not sure though that we can do that with kanboard. I know that Kanboard can be very capricious with permissions…
We could also create an account on demand for anyone who wants to contribute
I’m going to have a look to the different options available with kanboard
So, after a few test, it appears as I expected that there’s no “easy” solutions.
If we want to give a public access to this kanboard, here 3 solutions I see:
- Create an account to everyone is asking for. Means also anyone who’s not asking will not have any access.
- Create an “Guest” account with a simple password. This account could have only read only access to the boards.
- Use the public address of the pad, but this address is very uncomfortable to use.
We could install yourls or lstu to shorten this url though.
Can the Kanboard notification for update be integrated in a closed matrix group or Xmpp?
For now, I cannot give my opinion about your propositions @Maniack_Crudelis as I don’t know what is usage is done with this Kanban.
What is its purpose ? Is it explained somewhere and I missed it ?
Is it about officials apps only or also community apps and helpers ?
You would like to have the notifications of kanboard on xmpp ?
It’s probably possible with one of the many plugins available.
But, it’s going to be almost the same thing than what we already have from github.
We’re using this kanboard to know what’s the status of each PR for the official apps, so we can know what should be done for each PR.
That’s very useful because we can quickly now on which PR we have to work.
However, it’s only about official apps, not community one, because it’s mainly design to be used by the Apps group.
We also have another board for others PR related to the apps, like helpers or our CI tools. But, it’s not widely used…
In addition to ppr’s Raspberry, we now have 2 new Raspberry in our pool.
One from Gofannon and another one from Maniackimanis.
So we have now 4 Raspberry ready to work for our CI \o/
Our current arm CI is crashing every day because of a lack of memory on samourai.
OSError: [Errno 12] Cannot allocate memory, yesterday at 22:15.
So, I’m going to move this CI on another server, and because this CI doesn’t need a full package_check with lxc to run, I’m going to put in on the same container than ci-apps on bearnaise.
This CI does not need a lot of memory, so it shouldn’t be a problem to run it aside of ci-apps.
I’m currently modifying the app YunoRunner to use it as a multi-instance app.
Indeed… I forgot this one…
I’m also going to put this one back on business, but I’ll probably not enable xmpp for now.
Instead, @Aleks, as soon as you have some free time. Could we work on dash to use the json file from the CI instead of parsing the log files of each apps.
You can find a example file here, https://ci-apps.yunohost.org/ci/logs/list_level_stable.json