My "integration Level" falls from 7 to 0 ?!?

GitHub - YunoHost-Apps/pyinventory_ynh: YunoHost app package for: is currently:


On Yunohost Dashboard i can see that is was 7 then 6 and now 0 ?!?

Last run YunoRunner for CI seems to be fine and results in level 6

Currently i wait for scheduled: YunoRunner for CI

Eeeeh yeah, i dunno:

31372 INFO [######+++++++++++...] > Install project via pip...
43120 WARNING ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. 

Sounds related to something that changed in pip’s behavior maybe ?


where did you found this?!?

EDIT: Okay i run a test by myself and found it, too:

425142 DEBUG Collecting tablib[html,ods,xls,xlsx,yaml]>=3.0.0
425144 WARNING ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
425146 WARNING     tablib[html,ods,xls,xlsx,yaml]>=3.0.0 from (from django-import-export==2.6.1->-r /opt/yunohost/pyinventory/requirements.txt (line 48))
426266 DEBUG + ynh_exit_properly

Seems that this is the problem in pip: Error installing requirements with extras & hashes with new resolver · Issue #9644 · pypa/pip · GitHub

The “work-a-round” is to use “–no-deps” and that’s find in my case and it works.

Commit: Use pip install with "--no-deps" · YunoHost-Apps/pyinventory_ynh@8d2ea6d · GitHub

@Aleks Thanks to point to the problem :wink:

1 Like

I had a look at the last run : went to the repository, clicked the ‘Integration level 0’ badge at the top of the README, clicked on the “2 days ago” right to the Stable line, ended up on YunoRunner for CI then I checked the logs for job #4169 (well that’s indeed a bit not obvious if you don’t know about the first two links … but anyway, you can also go to YunoRunner for CI and click your app and check the last failed log


I change the useless “CI Pipeline” link from to → :wink:

btw. the CI machine is very slow, isn’t it?!? It seems to take days for scheduling…

1 Like

It’s not that it takes days to schedule, it’s more like the test is pending while other tests are being ran :sweat_smile:

You can see the queue on the ci home page (main CI) or (dev CI) and these days there’s indeed a shitload of pending jobs and the CI can’t keep up :sweat_smile: (+ some technical issue making jobs crash ugh, gotta find some volunteer with time to dig into it)

titus offered to trigger jobs on his own CI in the meantime

1 Like

Sorry my bad english :wink:

It would be great if a CI run can be made via github actions and if there is a YunoHost Package ru easily run a own CI server :wink:

Indeed, I’m very new to the Ynh packaging world, but was impressed by how cluttered the CI queue was :grimacing: :grinning_face_with_smiling_eyes: I try not forgetting what I’m testing while waiting for the result ^^

That’s very nice !

Aren’t Github actions free for open source projects ?

Agreed !

Oops looks like we are asking for something already existing

1 Like

Oh cool! I didn’t know anything about GitHub - YunoHost-Apps/yunorunner_ynh: YunoRunner package for YunoHost

Great! I will try this, see also: Package-check usage in a virtual machine?!? - #7 by jedie

Yes… I use it in my projects for higher level tests. I run pytest and the YunoHost apps package linter via actions, see: Workflow runs · YunoHost-Apps/pyinventory_ynh · GitHub

Sure (apart that it increases our dependency to Github :sweat_smile: ) but that wouldnt solve the issue I believe : ultimately testing an app is a lengthy process and it’s not unusual that the full chain takes at least 1 hour (for many technical reasons) - and I believe that github actions are limited to 1 concurrent worker accross the entire organization. Hence you would get the same issue of too-many-job-pendings accross the 200~300 app repositories all in yunohost-apps org :confused: :sweat_smile:

1 Like

That’s true, but we could then run the CI in our own repo and submit it to the official CI (GitHub or not) only once we are sure our app reaches the target level :slight_smile:

1 Like

drop from level 6 to level 2 happens again, see: Python package: Upgrate/Restore failes on CI :unamused: