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

Utilize odkrunner #719

Open
Tracked by #435
joeflack4 opened this issue Dec 6, 2024 · 6 comments
Open
Tracked by #435

Utilize odkrunner #719

joeflack4 opened this issue Dec 6, 2024 · 6 comments

Comments

@joeflack4
Copy link
Contributor

Overview

We should utilize ODK runner instead of run.sh.

Additional info

@joeflack4 joeflack4 self-assigned this Dec 6, 2024
@joeflack4 joeflack4 added enhancement New feature or request productivity stability and removed enhancement New feature or request labels Dec 6, 2024
@twhetzel
Copy link
Contributor

@joeflack4 do you want to try this for updating to ODK 1.5.4?

@joeflack4
Copy link
Contributor Author

joeflack4 commented Dec 10, 2024

I'm not in a rush to do this. I did notice when updating my images locally that there was a new image, but unless there's a specific benefit to a patch version, I feel it's better to wait.

Unless you or Nico know of a specific reason that we should upgrade to this version.

Similar with this one. This is a nice-to-have. So I'm not in a rush though I could do it after completing my January release issues.

I could do these in the same PR or separate; either way.

@matentzn
Copy link
Member

I don't think there is anything "to do" to switch to ODK runner other than adding something to the documentation? We could possibly add a goal to upgrade ODK runner to the makefile but setting it up is a local job.

@joeflack4
Copy link
Contributor Author

Good point. Well, looks like it's only a couple hundred kb (that makes me happy); in that case personally I'd commit that. But if we do, I agree; would still update the docs about using it.

But I guess the standard practice for a binary like this is manual setup, adding to global packages, if we just wanna go that route.

@joeflack4
Copy link
Contributor Author

As for ODK version, I suppose @matentzn doesn't see a reason to upgrade right now either? Or on the contrary, I wonder if you guys do want to upgrade the mondo-ingest config on every minor/patch update, rather than case by case?

@matentzn
Copy link
Member

I think it makes sense to update versions frequently as the minor versions are all about upgrading sssom, oak, robot etc.. So I would be in favour of upgrading. Minor updates don't happen more than once every two or three months, the last two were a real exception

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

No branches or pull requests

3 participants