Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wishlist #10

Open
4 of 8 tasks
alexAubin opened this issue Dec 29, 2020 · 3 comments
Open
4 of 8 tasks

Wishlist #10

alexAubin opened this issue Dec 29, 2020 · 3 comments

Comments

@alexAubin
Copy link
Member

alexAubin commented Dec 29, 2020

  • 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..)
  • Have some uri like /apps/<appname>/latestjob that points to the latest job completed/ongoing for an app #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...)
  • 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).
    • 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
    • + 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
Copy link
Contributor

  • 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
Copy link
Contributor

tituspijean commented Jun 6, 2021

There are some quirks upon installation with yunorunner_ynh:

  • config.py lacks DEBUG and PORT keys
  • ciclic has a hardcoded DOMAIN=localhost:4242 which should be imported from config.py instead
  • 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
Copy link

orhtej2 commented Oct 18, 2023

  • 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants