At the moment, part of the preparation for deploying changes to my repository is very manual and can be interrupted by merges of other PR's.
The reason it can be interrupted is that as part of the preparation of my deployment, I am having to create a PR to update the requirements.txt file, for the deployment (to have the latest versions).
Moreover, my repository has dependencies on two other repositories, and when there is a PR merge in those repositories, my repository will automatically update the version of those repositories in requirements.txt.
So you can see that if during my deployment PR, someone merges to those repository, it will delay my deployment PR, as I will need to hit Update Branch to get the most up to date version of Master.
My idea is to automatically create a deployment PR each time someone merges to Master to any of the three repositories.
In that way, when I am ready to deploy, I have and can use the 'latest' deployment PR that was automatically created, and if anyone merges to any of the three repositories after that, it will just fall into the next deployment.
In my script, I have:
if [ "$staged" == "requirements.txt" ] ; then
echo committing and pushing requirements.txt .. should be only on master and not on rebuild
git commit --no-verify -m "Version updates by Jenkins master build, ticket ${jira_ticket_name}" requirements.txt || exit 3
git push origin HEAD:master || exit 2
exit 0
I have added the above few lines of code to the build scripts of my repository, so that everytime someone creates and merges a PR, the above will run and a new deployment PR will be created automatically.
My worry, and I am yet to test it, is that during the build process, when the above is run, git push will not work since it is not coming from a PR. Am I right to be worried about this?
There is much more to the above code, please let me know if more information is needed.