-
Type: Task
-
Status: Resolved
-
Priority: Minor
-
Resolution: Done
-
Affects Version/s: NXP-6.0, NXP-7.x, NXP-8.x
-
Component/s: Continuous Integration
-
Epic Link:
-
Tags:
-
Story Points:3
1 day before the release date:
- send a mail notification announcing the build start and asking for no commit (Jenkins plugin ?) on tomorrow
- send a slack notification on dev channel to say the same (Jenkins plugin ?)
-> this will have to be done on friday for monday releases? or weekend release will then be authorized? - send a mail notification to the reviewer(s) (mail to be defined) containing a list of tickets (links included) with the current title and the current value of the field (with a flag saying if it will be included or not). Eventually this mail could contain an MD formatted release notes to see a preview (could be generated using ./releaseNotes.sh md 7.10-HF30)
the day of the release:
- job should check if there are any JIRA blocker tickets for the current HF branch
- job should check if there are any Test'n'push running for the current HF branch
- send a mail notification announcing the build start and asking for no commit (Jenkins plugin ?)
- send a slack notification on dev channel to say the same (Jenkins plugin ?)
- update JIRA release ticket saying notifications were sent
- update JIRA release ticket saying the build was started
The checks could be performed in a script that would fail if there is at least one blocker ticket or if there is at least one TnP running for the current HF branch.
In case of build failure and to avoid sending again the notifications, the job should check the JIRA release ticket for the start notification update.
The same for the sent notification comment.
The build started comment should be added thought everytime the build is started for traceability.