I wanted to inform you all on the work that’s been ongoing for the past 3-4 months on The Foreman Community’s CI infrastructure. There’s been a large effort by @ehelms, @Zhunting, and me to
I’m happy to announce that as of this morning pull_request_scanner has been deleted from ci.theforeman.org!
All jobs that are currently on Jenkins are now JJB’d and GHPRB’d (where applicable) in the foreman-infra repo. Huge thanks to @ekohl for the amount of time he spent reviewing and re-reviewing foreman-infra pull requests.
The string to re-trigger jobs for most pull requests has changed slightly due to GHPRB wanting a context name. If you’re wanting to kick a pull request job look in the Checks section and you should see the context name in bold. Just comment [test <name>] (i.e. - [test foreman-tasks]) and you’re off to the races! The new job should almost instantly from when you submit the comment, so let me know if that isn’t happening.
My immediate next step is to include a script in our Jenkins puppet deployment to delete any jobs that are not in JJB. I can’t prevent you from creating a Jenkins job in the web interface, but I can tell you it’ll only live about 30 minutes or less before getting garbage collected. We want everything to be JJB from this point forward, so please keep that in mind.
IIRC there’s a purge flag to JJB itself, I remember looking at it and wondering how long it would be before we could use it when I first implemented JJB… 3 years ago…
Yeah I’ve looked into the --delete-old flag and it only deletes jobs previously managed by JJB no longer present in the configs. It looks for the <!-- Managed by Jenkins Job Builder --> comment in a job’s description. If that’s not present, it won’t touch it.
It is indeed that bit. In the screenshot you can use [test foreman] or [test katello] or [test upgrade] to rerun that specific check. They can also be in the same comment if you want to rerun multiple checks.
The largest reason is that pull_request_scanner added a lot of complexity to our Jenkins environment (IMO). It required more jobs be chained together. It consumed a job slot on a worker node whenever it was running. At one time, it could take up to 30 minutes before the scanner would pick up a pull request or re-test a pull request. As of late, pull_request_scanner seemed to have gotten more fragile. I’ve noticed it had started missing some pull requests or failing to respond leaving a pull request in a ‘pending’ state indefinitely.
At the time when pull_request_scanner was created, Github Pull Request Builder didn’t exist, but the scanner solved our problems.
Github Pull Request Builder offers a lot of improvements over our pull_request_scanner. It allows us to simplify our jobs. It takes care of checking out the pull request content for us. Since it’s event-based (as opposed to pull_request_scanner's polling model) new pull request jobs are triggered almost instantly and we don’t have to keep secret authkeys sitting in the job configurations anymore.
) so I was unaware of the distinction. Carry on 
