Add a GitHub Action to publish releases on PyPI #65
Conversation
|
I created the namespace with an empty release. PyPI no longer accepts registering namespace without a package. It is in the IOOS org at https://pypi.org/project/xarray-subset-grid/ |
|
Hmm -- presumably we could use pixi to set up the build environment -- but maybe that wouldn't be helpful? And while you are looking at the CI -- can you figure out how to use variables to set the pixi version, etc in: test.yaml? (or maybe the dependabot can keep those updated?) |
What needs tweaking? |
As I mentioned above, it may need tweaking. We would only know after the GHA runs. Now we know. Both the sdist and the wheel are build and tested in the CI.
Yeah, it is kind of an overkill. We only need
You mean the versions of the GitHub Actions? Sure, for security reasons it is recommended to use a fixed released version hash, like in the file I added, and then add the version as a comment. Dependabot will update the Action and the version in automated PRs. |
|
@ChrisBarker-NOAA I know it is super convenient to commit directly to |
| pixi run --environment ${{ matrix.environment }} test | ||
| - name: Lint | ||
| if: contains(${{ matrix.os }}, "ubuntu") && ${{ matrix.environment }} == "test310" |
There was a problem hiding this comment.
This is not working yet. I need to check GHA docs. However, if we go the route proposed in #66, we should remove linting from here anyway.
There was a problem hiding this comment.
Why not keep it the way it was? it worked, and I prefer the lint to be a separate job anyway.
Putting it in the matrix, and then selecting out only part of the matrix seems like complication for no reason.
But if it's made a pre-commit hook, then as you say, a moot point.
well, that is absolutely the way to go once a project is established and has a release but when there's a lot of churn to get the first one out, it gets in the way -- while it's a challenge to keep your PR up with main, it's even more a challenge if I"d been making changes in yet another branch -- how would you sync easily with that? Anyway -- we are almost there now -- is this ready to merge, or do you want to do #66 first? Hmm -- I see that: Is taking a VERY long time on the CI (for two jobs anyway, not sure why it hasn't timed out yet) That's a bad test anyway -- downloads a big dataset to test on -- I really had a hard time getting the devs to "get" how unit testing is supposed to work. Until I can fix that with a better test, maybe we should just skip it -- or not run any of the "--online" tests at all. |
|
OK -- I updated the test task to not inlcude the online tests. there's now a "test_all" task that does. For now, we'll only run the test task in the CI -- the online tests are really more integration tests anyway. It's in the Or I can merge that into main now, but it seems you didn't want that ... |
That is fine if it is via PRs. PRs are more visible, review, etc. I prefer to avoid direct commits to |
|
OK -- merged the test fixes in (#69) -- that should be better now. |
@ChrisBarker-NOAA this one should be ready. Once merged I'll rebase and finish #68. |
|
Sounds good -- thanks! |
|
So how do we trigger a build / publish? Make a gitHub release? |
Yep. Do you want to mint one? |
|
@ocefpaf : how do we actually push to PyPi? Does making a github release by hand trigger the build? |
Yep. All you need is to make a GitHub release. |
I also added a dependabot config to keep the GitHub Actions updated.
Note that we may need to tweak the pyproject.toml before merging this.
Closes #12