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.

Sign up for GitHub

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

MedGen build error #24

Merged
merged 1 commit into from
Apr 28, 2024
Merged

MedGen build error #24

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/buid_and_release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ on:
jobs:
build_and_release:
runs-on: ubuntu-latest
container: obolibrary/odkfull:v1.4.1
container: obolibrary/odkfull:latest
Copy link
Contributor Author

@joeflack4 joeflack4 Apr 28, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

The fix

This was the problem. This older version of the production ODK container was not up-to-date enough.

Advantages to latest > fixed version

  • Have access to the latest features and fixes.
  • Don't have to worry about checking that the version is up-to-date / correct whenever work is done on the repo.

Disadvantages

  • Can introduce breaking changes (it's because of this that I chose a fixed version before)

Alternatives? (probably not)

It could be nice to use a wildcard * on the minor or patch version, but not the major version. However, upon some googling, generative AI suggested I can do this, but search results and my terminal (invalid reference format) show that I cannot. That makes sense. I think container tags are only string labels; doesn't support a proper versioning system like semver.

Copy link
Member

Choose a reason for hiding this comment

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

I personally prefer fixed versions to minimise churn from breaking changes. These happen more frequently as python code ages..

But I dont mind strongly in this case.

Copy link
Member

Choose a reason for hiding this comment

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

(Note that we may not be monitoring dozens of repos with actions which we rely on to supply as with up to date data. If one of them stops working, maybe we would never know).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After I merged this, I thought about it later and I think I agree with you. I made a new PR and fixed it to 1.5:

If one of them stops working, maybe we would never know).

@matentzn Just to clarify. Are you saying that this is a risk of setting the version to latest? And, additionally, are you just not sure if (the appropriate) people are receiving (and actually taking seriously / reviewing) notifications for GH action failures?
For me, I see them as an email and I always review, but IDK about others.

Copy link
Member

Choose a reason for hiding this comment

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

And, additionally, are you just not sure if (the appropriate) people are receiving (and actually taking seriously / reviewing) notifications for GH action failures?

I can tell you for myself that I receive hundreds of notifications daily and I will miss many; and I know that compared to many people I know that are even more busy that they will be guaranteed to miss theirs.

Copy link
Member

Choose a reason for hiding this comment

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

. Are you saying that this is a risk of setting the version to latest?

Using a versioned container should minise the risk of failure, as no upstream tool changes can impact the execution.

steps:
- uses: actions/checkout@v2
- name: build
Expand Down
3 changes: 2 additions & 1 deletion requirements.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ deprecation==2.1.0
distlib==0.3.6
exceptiongroup==1.2.0
filelock==3.9.0
greenlet==3.0.3
hbreader==0.9.1
idna==3.6
importlib_resources==6.4.0
Expand Down Expand Up @@ -47,7 +48,7 @@ six==1.16.0
sortedcontainers==2.4.0
SPARQLWrapper==2.0.0
SQLAlchemy==2.0.29
sssom==0.4.6
sssom==0.4.7
sssom-schema==0.15.2
stevedore==5.0.0
tomli==2.0.1
Expand Down
Loading