-
Notifications
You must be signed in to change notification settings - Fork 4.5k
metadata-service[lib]: change metadata upload logic for release candidates #44509
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
metadata-service[lib]: change metadata upload logic for release candidates #44509
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @alafanechere and the rest of your teammates on |
bbdcb0a
to
ba31fd5
Compare
fb3fc3b
to
80de6c1
Compare
ba31fd5
to
3ccc18d
Compare
80de6c1
to
d6a6a60
Compare
3ccc18d
to
c678426
Compare
d6a6a60
to
2bbf721
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved with a couple of minor requests.
I'm not too familiar with the publishing pipeline. Since there are no unit tests, have you tested these changes manually?
@@ -144,6 +144,10 @@ def _latest_upload(metadata: ConnectorMetadataDefinitionV0, bucket: storage.buck | |||
latest_path = get_metadata_remote_file_path(metadata.data.dockerRepository, "latest") | |||
return upload_file_if_changed(metadata_file_path, bucket, latest_path, disable_cache=True) | |||
|
|||
def _release_candidate_upload(metadata: ConnectorMetadataDefinitionV0, bucket: storage.bucket.Bucket, metadata_file_path: Path) -> Tuple[bool, str]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks almost identical to _latest_upload
on line 143. Should we move "release_candidate" (and "latest", from line 144) to constants, and then have just a helper function _upload
that takes it in as a variable, instead of two helper functions?
is_pre_release = validator_opts.prerelease_tag is not None | ||
is_release_candidate = metadata.data.release.is_release_candidate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth adding an assertion that is_pre_release
and is_release_candidate
aren't both True
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both can be True
. It's determined as a pre-release from options passed to the metadata upload CLI (which originally come from an airbyte-ci connectors publish
inputs.
So nothing prevents you from having is_release_candidate
set to True
, but wanting to release a pre-release
for testing (usually from your branch).
This is why I added should_upload_release_candidate
and should_upload_latest
which would both be falsy if the it's a pre-release
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay that makes sense to me. Thanks for clarifying.
# - the current metadata to the "latest" path | ||
# - the current doc to the "latest" path | ||
# - the current inapp doc to the "latest" path | ||
if should_upload_latest: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll eventually want to move this logic into a helper function so it can be accessed by the final part of the RC publishing pipeline. But all good if you want to leave it here for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I envision the "final part of the RC publishing pipeline" to be orchestrated via an airbyte-ci
command which would:
- Delete the
release_candidate/metadata.yaml
file (could be done in this package) - Set the
isReleaseCandidate
field tofalse
inmetadata.yaml
(could be done in this package) - Push the current version with the
latest
(will likely be done directly inairbyte-ci
)
So I don't think a change here is required: the update of the metadata.yaml
isReleaseCandidate
field will change the behavior of the upload function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay cool, that sounds good.
c678426
to
46977fc
Compare
2bbf721
to
1e0f886
Compare
46977fc
to
c088c5b
Compare
1e0f886
to
712ff3f
Compare
# - the current metadata to the "latest" path | ||
# - the current doc to the "latest" path | ||
# - the current inapp doc to the "latest" path | ||
if should_upload_latest: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay cool, that sounds good.
Merge activity
|
712ff3f
to
63e2cfd
Compare
What
Relates to https://github.com/airbytehq/airbyte-internal-issues/issues/9403
When a connector metadata is flagged as a release candidate we should upload it to a dedicated path in GCS, so that it will not be picked up by the registry as the latest version.