nuclearsandwich
commented
2 years ago I'm proposing this versus manually triggering the nightly jobs, thus polluting the job history.
If this is just for convenience I have reservations.
I appreciate not polluting job history. If there was a straightforward way to block manually triggering the nightly jobs I'd put that on. There really isn't a circumstance where it is required.
All of the asan/tsan jobs are reproducible with the current manual CI jobs by setting specific parameters.
If we add another manual job then we have to store yet another set of job histories and add to the growing list of jobs that CI builders need to avoid in most cases. It would be extra weird if a manual CI job defaults to a non-default platform for specific job types just because.
If we want to make triggering these manually easier then I can draft you a python script that will trigger the standard manual CI job with a given set of parameters as long as you have a Jenkins token in your environment.
If instead there's a desire to both trigger these manually and have them periodically then we would need periodic jobs rather than just additional manual CI jobs and unless there are blockers to running such jobs on build.ros2.org I'd like to try and push new CI jobs there unless they specifically need Windows.
jacobperron
Useful for triggering on PRs targeting asan/tsan issues and for running on older support platforms (e.g. Ubuntu 20.04).
I'm proposing this versus manually triggering the nightly jobs, thus polluting the job history.
Let me know if there's something else that needs to be done to make these new jobs available on ci.ros2.org.