...
Jenkins jobs in staging environment will poll the repositories every 10 minutes to check if any new tags are created in the repo.
If new tag is found, the code will check if the tag is created in the deployment window. Lets say 16:00:00 to 18:00:00.
The start and end times are configurable using 2 variables in Jenkins - START_TIME, END_TIME
The tag will also be checked if it has a _RC string and whether it matchs the current release pattern. This is to prevent non RC tags to not trigger deployments and hotfix tags to not trigger staging deployements.
Example -
release-2.10.0_RC1 is valid
release-2.10.0, release-2.10.0_ABC, release-2.8.7_RC1 are invalid
Once the above check is passed, a new jenkins job is automatically created with the tag name.
Based on the job names, the respective build, upload and deploy jobs will be triggered.
A slack notification will be sent for successful build and successful deployements.
For intermediate jobs like uploading the docker image, artifacts etc, success notifications will not be sent and only failure notifications will be sent
...
Certain builds when triggered parallely, causes overwriting of maven artifacts with a different code
Current design: Do nothing. If things break, it will be a reason to push teams to ditinguish distinguish their maven artifacts
Solution desired: Version the maven artifatcs properly in pom.xml and also use different naming conventions per service
...
Different repos have different release version
Current design: Trigger those manually
Planned change: Have a list of relase release versions that we can match against to solve different repos having different release versions. Example - release-2.10.0, release-1.2.0, secor-0.25
Tags created outside the deployment window will fail and not trigger itself again
Current design: Ask teams to not create tags in non deployment window
Planned change: Have a file to track such failed jobs and re-trigger them during the deployment window