Wishlist

[alexAubin]

• [ ] A different handling and display for "the test miserably failed" (e.g. because it timed-out or some other epic crash) versus. "the app is level 0 / bad quality"
• [ ] Have a "current job" in the top menu bar ? And/or have proper sections like "ongoing", "scheduled" and "completed/past jobs" on the home page. The issue currently is that when there are too many jobs scheduled, the currently working job won't be displayed or scroll near the very bottom (or you gotta go to the Apps page..)
• [x] #47
• [ ] When "restarting" jobs, the "created date" is not changed ... on one hand this is good because the re-created job will be top-priority (compared to newer jobs) ... but once the re-run job completes, the job ain't displayed in number 1 position on the home page ... I believe the fix should be to sort jobs according to "end time" on the home page rather than "created time" ? (but scheduled jobs don't have an end time yet...)
• [x] It should be clarified if yunorunner is meant to be a project-agnostic job handler, or on the contrary if it's yunohost-specific. This is related to the fact that currently yunorunner has several features to list apps and automatically add jobs - but it doesn't handle the 'dev CI' use case where jobs could be created by users for specific branches / folders. There's also the use case of testing/unstable/next-debian campaign where it's nice to have full manual control over the job scheduling via ciclic. Personally I'm favorable to embracing a yunohost-specific approach and merge yunorunner + CI_package_check (which doesn't necessarily imply to rewrite everything in python idk).
  • [x] Add coverage for the "dev CI" use case, which imho can be done with a small form when the user enters a git repo url + branch name to test, and ideally some form of loose authentication (with a token or idk) to prevent abuse from random strangers on the internet, and that's it
  • [x] + Serve some jenkins-like badges for job scheduled/ongoing/succeeded/failed ? (<-- for dev CI use case, c.f. the badges some people use in PRs ... ideally also making the job accessible using its name with something like /job/<jobname>)
  • [ ] Ideally if yunorunner is stated as a yunohost-specific, we could even display the level of the app in the UI

[Salamandar]

• [ ] Duration for each job, maybe mean duration of Repo
  • [ ] Progress bar and ETA for job in progress

The first one I'd like to try do a PR, the second one i don't have the knowledge.

[tituspijean]

There are some quirks upon installation with yunorunner_ynh:

• [x] config.py lacks DEBUG and PORT keys
• [ ] ciclic has a hardcoded DOMAIN=localhost:4242 which should be imported from config.py instead

• [x] Display the badge in the job page, and offer to copy its Markdown code (for hook-less use of the CI)

A different handling and display for "the test miserably failed" (e.g. because it timed-out or some other epic crash) versus. "the app is level 0 / bad quality"

Maybe it would make sense to display the app level instead of done? Then the available badges would be scheduled, running, failure (for a failure of the CI itself), and level <level> badges to show the result of the CI if it ran without failing?

[orhtej2]

• [ ] Ability to test custom URL/subpath as criteria for successful install
• [ ] Ability to grep the web contents to assess that the installation succeeded (currently 503s masked as 200s are considered success).