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

Reconsider CI management #3565

Open
effigies opened this issue Apr 18, 2023 · 5 comments
Open

Reconsider CI management #3565

effigies opened this issue Apr 18, 2023 · 5 comments

Comments

@effigies
Copy link
Member

          > Looks like CI is broken; apologies. @ghisvail If you have time to look into this, it would be appreciated. Otherwise I'll get to it this week.

It looks like issues with CI started to surface on the last two merged PRs. CI complains that jobs no longer find black or pytest although they appear in the install step in the logs. The only reason I could think of is that the venv is no longer visible or activated between calls to the CI scripts (perhaps as a result of a change in GitHub Actions behaviour)?

Perhaps we could refactor CI to not use a dedicated venv? Maybe there are good reasons for it, I have just never seen it done in practice with GHA since each job is executed in a separate throwaway container anyway. It might also make things considerably simpler, as I find the current flow of CI scripts quite hard to follow. Let me know what you think.

Originally posted by @ghisvail in #3529 (comment)

@effigies
Copy link
Member Author

Yeah, I now regret the tools/ci approach. The idea was to make it easier to switch between CIs by creating a minimum set of scripts that would work locally, so the learning curve for a new CI would just be "how do I run these scripts?". Now that I know GHA better, it's pretty confining... I think tox or hatch would be much better tools for that purpose.

I agree we can drop the venvs now. It used to be useful to avoid accidentally depending on your build tools in your test environment. pyproject-build has completely made that unnecessary.

@ghisvail
Copy link
Contributor

Now that I am getting very familiar with Hatch, I could give it a go if I have got your green light for it?

@effigies
Copy link
Member Author

Have you found integrating Hatch with GHA nice? https://github.com/ymyzk/tox-gh-actions makes working with Tox trivial.

That said, I'm okay with it in either direction. I just wouldn't spend a ton of time on any maintenance tasks in Nipype 1, as it really can't outlast Python 3.11 without a significant effort that would be better directed toward pydra.

@satra @oesteban Any thoughts?

@ghisvail
Copy link
Contributor

Have you found integrating Hatch with GHA nice?

It's basically two steps: pipx install hatch followed by hatch run <command>.

Provisioning and configuring the runtime is handled by actions/setup-python and some environment variables if need be. Configuring tox-gh-actions looks a bit more involved but definitely doable too.

@effigies
Copy link
Member Author

If hatch works smoothly, that's fine with me.

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

No branches or pull requests

2 participants