Skip to content
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

CU-8695hghww backwards compatibility workflow #478

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

mart-r
Copy link
Collaborator

@mart-r mart-r commented Aug 27, 2024

Add a new step to GHA workflow that does the following:

  • Downloads all (fake) models for various versions
    • 1.2.9, 1.3.1, 1.4.1, 1.5.3, 1.6.1, 1.7.0, 1.8.0, 1.9.0, 1.10., 1.11.0, 1.12.0
    • These are fake models created with the fake data as per CU-86956du3q revisit regression #470
    • They do not contain MetaCATs or RelCATs
  • Makes sure they all work
  • Cleans up afterwards

This PR depends on #470 and the GHA workflow will fail without it having been merged in since some of the necessary parts don't exist or are in a different state.

@tomolopolis
Copy link
Member

@mart-r
Copy link
Collaborator Author

mart-r commented Sep 4, 2024

Updates the zip in S3 bucket to include 1.13 built model pack.

Reran the latest GHA workflow to run it through that as well.

Copy link
Member

@baixiac baixiac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Does this mean each future release of MedCAT will request a new fake model be created and uploaded to S3? Is this part of the standard release process?

@mart-r
Copy link
Collaborator Author

mart-r commented Sep 9, 2024

LGTM. Does this mean each future release of MedCAT will request a new fake model be created and uploaded to S3? Is this part of the standard release process?

There is currently nothing in the release documentation to do this.
But if/when this gets merged in, I think such a step should be added to the release documentations.
Though there is currently nothing to ensure that the most recent release has a fake model in the bucket. That might be a good addition.

With that said, adding a compulsory step for this could complicate the release process. After all, whoever is doing the release would need to download the existing models, unzip, create a new model with the new release, upload back on to S3.
This requires additional time as well as access to the S3 bucket.
But I think it would still make sense to add it in the (minor or major) release documentation. With perhaps a note to contact someone else to do the model updates if needed.

@baixiac
Copy link
Member

baixiac commented Sep 9, 2024

After all, whoever is doing the release would need to download the existing models, unzip, create a new model with the new release, upload back on to S3.

Yes, documentation will help. Also, some automation could be done as part of the release workflow, ref. configure-aws-credentials.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants