Overhaul CI and CD workflows

PyPSA / linopy

Linear optimization with N-D labeled arrays in Python

https://linopy.readthedocs.io

MIT License

155 stars 43 forks source link

Overhaul CI and CD workflows #325

Closed afuetterer closed 1 week ago

afuetterer commented 2 weeks ago

As previously discussed here: https://github.com/PyPSA/linopy/issues/313#issuecomment-2213371885.

I would like to propose the following changes. These might be used in the other PyPSA repos as well, if desired.

Have a CI workflow, including pytest etc, and one run of "baipp", running on PR and push to master
Have a CD workflow, running on tag, creates a GH release, publishes to PyPI and what else is desired.

Proposal to follow these guidelines: https://learn.scientific-python.org/development/guides/gha-pure/ As used in their template: https://github.com/scientific-python/cookie/tree/main/%7B%7Bcookiecutter.project_name%7D%7D/.github/workflows

What do you think?

FabianHofmann commented 2 weeks ago

Great initiative @afuetterer! I think that sounds good, let's hear what @lkstrp thinks :)

lkstrp commented 2 weeks ago

Structurally there is no big difference to what is currently done in PyPSA, is there? But building wheels instead and adding artifacts looks great, so let's go!

afuetterer commented 2 weeks ago

No, not really that big of a difference. But having ci and cd in all your repos males it much more readable, I think. Sometimes you have "tests", "release", "deploy".

I will make a suggestion then?

afuetterer commented 2 weeks ago

Your cd workflows start by pushing a tag, right?

FabianHofmann commented 2 weeks ago

exactly

lkstrp commented 2 weeks ago

Your cd workflows start by pushing a tag, right?

Yes. Right now it's basically: tests -> CI, deploy -> CD. Except in linopy, there is also release, which should be moved in deploy/ CD.

In some repos there will be a validation CI soon. I think it is better to keep that workflow seperated from the Tests CI. Even if it could lead to some redundancy with the build job. So let's in my view, let's stick with tests.yml and deploy.yml (and in future validate.yml) everywhere.