Allow to automatically re-run jobs based on a schedule / event trigger

[sschuberth]

There are several reason why one would want to re-run jobs on a regular basis, even on the same repository revision:

• non-pinned dependencies might change dynamically
• new security vulnerabilities may have been discovered
• check against regressions in new ORT / Server releases

The above could be fulfilled by a cron-like definition of job schedules (and notifications for run results, but that's a bit of a different topic).

More generally, we probably need a concept or "run triggers", where time-based triggers are just one implementation. Other triggers could be

• new commits / tags in a repository
• some external event like a message in a Slack / Matrix channel

[sschuberth]

This might relate a bit to the discussion at #1560.

[mnonnenmacher]

We discussed this idea a few times internally and the conclusion was always that all CI environments allow scheduling jobs, so users can easily schedule this on their side. However, the basis for this was the assumption that users integrate the compliance checks into their build pipelines.

[sschuberth]

However, the basis for this was the assumption that users integrate the compliance checks into their build pipelines.

Yeah, that's probably not the case for a significant number of our users. Also, it would be more efficient to really only re-run the advisor to get up-to-date vulnerability information for unchanged code.

[mnonnenmacher]

However, the basis for this was the assumption that users integrate the compliance checks into their build pipelines.

Yeah, that's probably not the case for a significant number of our users.

For us it's the opposite, that's why we have not considered implementing this feature.
If that feature is important to you, it would be good to add a comment to #1560.