Feature #12160: Upgrade all systems to Stretch
Jenkins is not creating jobs for new branches
#3 Updated by intrigeri almost 3 years ago
- Status changed from Confirmed to Resolved
- Assignee deleted (
- % Done changed from 0 to 100
Post-mortem: we missed the breakage because the
git push that was failing (due to a hook that sanity-checks the generated jobs, that needed to be updated for Stretch) needs
2>/dev/null due to Git spitting out non-errors to STDERR. Ideally we would filter out the bits we don't want to see from STDERR, instead of ignoring it entirely. I've made sure that
update_tails_iso_jobs itself sends something to STDERR, so that cron tells us about the breakage, whenever that
git push exits with a non-zero exit code.
bertagaz: we should try to remember harder that
set -e is not enough in a cronjob, as cron ignores the command's exit status, and only emails us if there was any output.
#4 Updated by anonym almost 3 years ago
- Status changed from Resolved to In Progress
- Assignee set to intrigeri
- % Done changed from 100 to 80
- QA Check set to Dev Needed
The branches in the description have no Jenkins jobs still; IMHO this branch shouldn't be closed before all lost jobs are created, if possible. I'd at least want my above branches to be created without me having to push some nonsense to them just to make Jenkins notice them.
What are our options here?
#5 Updated by intrigeri almost 3 years ago
- Priority changed from Elevated to High
The branches in the description have no Jenkins jobs still; IMHO this branch shouldn't be closed before all lost jobs are created, if possible.
Crap! I'm sure I checked that they did have Jenkins jobs when I closed this ticket.
What are our options here?
I'll look into it shortly. Sorry!
#7 Updated by intrigeri almost 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
- QA Check deleted (
test/12131-retry-report-an-error was merged into stable, and our CI design is only about topic branches that were not merged yet. Generally merging the current base branch into the topic branch is enough to force Jenkins to build it again. But it won't work in this case as that topic branch is in the exact same state as stable currently. The good news is that this means you already get the CI results you want from the stable branch :)
Same for the other branch.
So it seems to me that the system works as designed, and that practical use cases we thought about are addressed already, so closing this ticket (the 2 branches Jenkins creates no job for are definitely not "new"). If this design doesn't work for you, please describe your use case in another ticket.