chore: set up release-please for updating cloudbuild yamls #700
Conversation
| @@ -14,7 +14,7 @@ | |||
|
|
|||
| timeout: 7200s # 2 hours | |||
| substitutions: | |||
| _JAVA_SHARED_CONFIG_VERSION: '1.6.0' | |||
| _JAVA_SHARED_CONFIG_VERSION: '1.6.0' # {x-version-update:google-cloud-shared-config:released} | |||
There was a problem hiding this comment.
Doesn't this and the other need to be <!-- {x-version-update:google-cloud-shared-config:current} -->? Otherwise, how is the release please PR check on the docker image existing going to pass?
In other words, won't this mean that JAVA_SHARED_CONFIG_VERSION is always one version behind what we want it to be in the release PRs.
There was a problem hiding this comment.
That's a good question! The reason behind this change is to avoid pushing new images for SNAPSHOT updates. (Please correct me if I'm wrong) My understanding is that the released corresponds to the first item in the value which gets updated when a new release PR is opened (e.g. #694). As a next step, I'm considering changing the Cloud Build for the docker image to be triggered based on a push to the release-please--branches--main so that we don't have to wait for the release PR to be merged before the docker image is pushed. However, opening to hearing alternative solutions.
There was a problem hiding this comment.
[Update] As discussed offline with @burkedavison, setting the job to re-push on a commit can lead to the image being pushed multiple times on the same PR. This can result in the blocking docker validation check showing false positive results (e.g it may verify for the old image but not the recently pushed one). Instead of having a separate check on the release PR to verify for the presence of the docker image, one option being considered is to have the release job wait for the docker image to be available before publishing the maven artifact.
mpeddada1
added
the
do not merge
For #691