Is it possible to change the push order for git-flow releases?
45 views
Skip to first unread message
Moshe Katz
Dec 10, 2020, 12:37:13 PM12/10/20
to smar...@googlegroups.com
Hello,
I use SmartGit for several projects hosted on a GitLab server that runs CI/CD jobs.
Because finishing a git-flow release modifies two branches and creates a tag, it causes the creation of three CI pipelines, one for each branch and one for the tag.
Ideally, I want the tag pipeline to run first so that I can use the results from it while the branch pipelines are still running. Since we have a limited number of CI runners available, if the branch jobs start first I need to wait for all three jobs to complete before I can use the output of the tag job.
Right now, when SmartGit does a push at the end of the git-flow release process, it pushes first develop, then master, then the tag.
My workaround is to uncheck the box to push the release and then do the push manually, but that's annoying and I sometimes forget.
Is there any way to configure it so the tag gets pushed first?
Thank you,
Moshe
syntevo Support
Dec 10, 2020, 5:02:48 PM12/10/20
to smar...@googlegroups.com
> Right now, when SmartGit does a push at the end of the git-flow release
> process, it pushes first develop, then master, then the tag.
> My workaround is to uncheck the box to push the release and then do the
> push manually, but that's annoying and I sometimes forget.
> Is there any way to configure it so the tag gets pushed first?
This is not possible. Pushing the tag first also seems wrong to me: the probability for a push failing due to concurrent server-side commits is highest for develop, somewhat less for master and significantly less for tags. Hence the current order which Git-Flow is using is reasonable.
> process, it pushes first develop, then master, then the tag.
> My workaround is to uncheck the box to push the release and then do the
> push manually, but that's annoying and I sometimes forget.
> Is there any way to configure it so the tag gets pushed first?
> Ideally, I want the tag pipeline to run first so that I can use the results
> from it while the branch pipelines are still running.
--
Best regards,
Marc Strapetz
syntevo GmbH
http://www.syntevo.com
> You received this message because you are subscribed to the Google Groups
> "SmartGit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> smartgit+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/smartgit/CALJwmGDCaX2oEqmyyr8dFKY9Hm4zYxmfdxjmuTzdbyz9rKWXiQ%40mail.gmail.com.
>
Moshe Katz
Dec 10, 2020, 7:57:48 PM12/10/20
to smar...@googlegroups.com
The difference between the build jobs is simple - we have set up our projects so that `v*` is a "protected tag pattern" and regular developers cannot push tags that start with `v`. We have CI jobs with the rule `if: '$CI_COMMIT_TAG && $CI_COMMIT_REF_PROTECTED == "true"'` that create our official release builds which we push to our servers and the Google and Apple stores. Because we need to complete the app submission (for mobile apps) and deploy the built code (for server-side apps), running CI jobs on the tag first reduces the amount of time we need to spend waiting for jobs to complete. For example, one of our projects has a pipeline that takes about 15 minutes, and we have one runner that is able to process that pipeline. This means a difference of 15 minutes vs. 45 minutes of waiting for the release build to run.
Regarding master and the tag pointing to the same commit, the problem is that GitLab CI runners do not know that information. A pipeline that runs for a branch does not know that there is a tag, and the pipeline for that tag does not know which branch it is on either.
I have one other colleague who is allowed to do releases and who does not use SmartGit, and I wrote the release documentation for him to run `git push --tags; git push origin develop; git push origin master` to get the order we want. This is also what I do manually when I remember to do so, but I don't always remember.
To view this discussion on the web visit https://groups.google.com/d/msgid/smartgit/5fd29b05.1c69fb81.45aaa.6a41SMTPIN_ADDED_BROKEN%40gmr-mx.google.com.
syntevo Support
Dec 11, 2020, 4:35:04 AM12/11/20
to smar...@googlegroups.com
> The difference between the build jobs is simple - we have set up our
> projects so that `v*` is a "protected tag pattern" and regular developers
> cannot push tags that start with `v`. We have CI jobs with the rule `if:
> '$CI_COMMIT_TAG && $CI_COMMIT_REF_PROTECTED == "true"'` that create our
> official release builds which we push to our servers and the Google and
> Apple stores. Because we need to complete the app submission (for mobile
> apps) and deploy the built code (for server-side apps), running CI jobs on
> the tag first reduces the amount of time we need to spend waiting for jobs
> to complete. For example, one of our projects has a pipeline that takes
> about 15 minutes, and we have one runner that is able to process that
> pipeline. This means a difference of 15 minutes vs. 45 minutes of waiting
> for the release build to run.
>
> Regarding master and the tag pointing to the same commit, the problem is
> that GitLab CI runners do not know that information. A pipeline that runs
> for a branch does not know that there is a tag, and the pipeline for that
> tag does not know which branch it is on either.
OK. Please consider to request this as RFE at:
> projects so that `v*` is a "protected tag pattern" and regular developers
> cannot push tags that start with `v`. We have CI jobs with the rule `if:
> '$CI_COMMIT_TAG && $CI_COMMIT_REF_PROTECTED == "true"'` that create our
> official release builds which we push to our servers and the Google and
> Apple stores. Because we need to complete the app submission (for mobile
> apps) and deploy the built code (for server-side apps), running CI jobs on
> the tag first reduces the amount of time we need to spend waiting for jobs
> to complete. For example, one of our projects has a pipeline that takes
> about 15 minutes, and we have one runner that is able to process that
> pipeline. This means a difference of 15 minutes vs. 45 minutes of waiting
> for the release build to run.
>
> Regarding master and the tag pointing to the same commit, the problem is
> that GitLab CI runners do not know that information. A pipeline that runs
> for a branch does not know that there is a tag, and the pipeline for that
> tag does not know which branch it is on either.
https://smartgit.userecho.com/
> > .
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "SmartGit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> smartgit+u...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/smartgit/CALJwmGBbYDTcXp1UiHHEf0iiNFK5RigseHHDL5p184h29uwv6Q%40mail.gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "SmartGit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> smartgit+u...@googlegroups.com.
> To view this discussion on the web visit
>
Reply all
Reply to author
Forward
0 new messages