search

BIMAU / transiflow

Implementations and continuation of some standard computational fluid dynamics problems using the finite volume method
Apache License 2.0
9 stars 12 forks source link

Continuous deployment #33

Open LourensVeen opened 1 month ago

LourensVeen commented 1 month ago

I'm looking at adding a CD setup to make it easier to make releases. The basic steps would be to use pip to build and then twine to upload, but we need to make some decisions as to how to set it up.

The first question is what constitutes a release, and thus triggers the CD. I can think of three possibilities: 1) a tag of the form vX.Y.Z-postfix (or similar) on a commit, 2) a commit to main (or master here I guess) as in git flow, and 3) a GitHub release.

Number 1) is simple but limited, 2) entails using a branching model that I like, but which may be more complex than what you want, and 3) ties you to GitHub but makes it easier to e.g. add a description of new features, and it's needed anyway for Zenodo integration for DOIs.

Second, do we want to support pre-releases? Those can be useful to test the package itself and whether everything works for the user installing it, but then this package is pretty simple so chances are it'll work anyway. The main issue is actually in the hard-to-install dependencies rather than in the package itself I think.

Note that this will anyway require some work on your side as well, because the various services need to be set up with accounts and tokens and such, and that's something you need to do.

Sbte commented 3 weeks ago

I'm looking at adding a CD setup to make it easier to make releases. The basic steps would be to use pip to build and then twine to upload, but we need to make some decisions as to how to set it up.

The first question is what constitutes a release, and thus triggers the CD. I can think of three possibilities: 1) a tag of the form vX.Y.Z-postfix (or similar) on a commit, 2) a commit to main (or master here I guess) as in git flow, and 3) a GitHub release.

Number 1) is simple but limited, 2) entails using a branching model that I like, but which may be more complex than what you want, and 3) ties you to GitHub but makes it easier to e.g. add a description of new features, and it's needed anyway for Zenodo integration for DOIs.

I think you need a tag for github releases, so github releases would be fine. I want tags for sure. Speaking of branches. Do you know if you can rename the main branch without breaking pull for existing clones?

Second, do we want to support pre-releases? Those can be useful to test the package itself and whether everything works for the user installing it, but then this package is pretty simple so chances are it'll work anyway. The main issue is actually in the hard-to-install dependencies than in the package itself I think.

I prefer to cover as much as possible by CI, and just do a x.x.1 release if that wasn't adequate.

LourensVeen commented 2 weeks ago

I think renaming the main branch will break clones, they would have to manually update the local branch using git branch -u main master if you've renamed master to main on GitHub. It probably makes more sense to just do git switch main though, to get a new local branch that has origin/main as its upstream automatically.

Okay, so we want to have an automatic deployment that triggers whenever a release is made on GitHub, and which then automatically releases to PyPI as a full release.