Make the auto_deploy:start job idempotent
If the job is idempotent, it allows release managers to safely retry the job in case of any errors.
Proposal
The following classes called by Tasks::AutoDeploy::Tag
are not idempotent.
-
AutoDeploy::Builder::Omnibus
-
#component_changes?
methodcomponent_changes?
compares the versions of different components (Gitaly, ElasticSearch indexer, etc) in the Omnibus branch and the Gitlab auto-deploy branch. It returns true if any version is different. However, if it returns true, a commit is added to the branch to make the component versions the same as the versions in the Gitlab branch. So if theauto_deploy:start
job is executed again,component_changes?
now returns false. -
#builder_changes?
methodbuilder_changes?
returns true if the auto-deploy branch in Omnibus does not have a tag. Ifbuilder_changes?
returns true, the latest commit on the branch is tagged. So ifauto_deploy:start
is executed again,builder_changes?
now returns false.
-
-
AutoDeploy::Builder::CNG
-
#component_changes?
method -
#builder_changes?
method
-
-
Release metadata is updated only when Omnibus and CNG are tagged. (tagger/omnibus.rb#L46, tagger/cng_image.rb#L47)
Release metadata is prepopulated using values from the previous auto deploy version (auto_deploy/tag.rb#L99). So, if the values are not updated, which happens when Omnibus or CNG have already been tagged (in a previous run of the
auto_deploy:start
job), the release metadata of the latest auto deploy version will contain old values.