ENH: Automated Package Building and Deployment

[esavary]

This PR introduces new jobs in the build_test_deploy CircleCI workflow for building and deploying the package to PyPI.
related to #152

[esavary]

@effigies @oesteban , I'm wondering if there's a clever way to test the code I added in the CircleCi workflow without needing to push a tag. (To prevent misunderstanding, @oesteban , you mentioned yesterday using TestPyPI to test the package, but what I'm asking here is a bit different—I'm looking for a way to specifically test the new CircleCI routine itself, not the package.) Any suggestions on this would be helpful!

[arokem]

In case it's helpful, here's what we do in pyAFQ using GA:

https://github.com/yeatmanlab/pyAFQ/blob/master/.github/workflows/publish-to-test-pypi.yml#L28-L39

On push, if this is not a tag, the package gets uploaded to test pypi. If it is a tag, it gets pushed to pypi. Can some similar conditional be implemented in circle?

[effigies]

For new workflows, I would strongly recommend adopting https://github.com/hynek/structlog/blob/main/.github/workflows/pypi-package.yml more or less wholesale. Its first action produces easily inspectable reports in the actions tab: https://github.com/hynek/structlog/actions/runs/8584514099

Since these actions are maintained, they are less likely to bitrot than custom scripts in CircleCI.

[arokem]

Based on #152 (comment), I believe that there's a preference to do this on CircleCI, if possible.

[esavary]

Thanks @arokem and @effigies for the suggestions! It seems a good idea to push to TestPyPI on commit and allow us to test the workflow. If we switch to GitHub Actions, do you think it's feasible to trigger tests on CircleCI and prevent the release in the GitHub Action workflow if they fail? (Similar to the mechanism described here: https://circleci.com/blog/trigger-circleci-pipeline-github-action/) This could potentially address one of the concerns raised by @oesteban in his comment #152

[effigies]

We can create a deployment environment that requires a maintainer to approve the release before pushing.

[effigies]

Here is an example of using an environment:

https://github.com/nipy/nibabel/blob/a2e5dee05cf374c22670ff9fd0d385ce366eb495/.github/workflows/test.yml#L199-L212

I created one here called "Release"

[esavary]

Here is an example of using an environment:

https://github.com/nipy/nibabel/blob/a2e5dee05cf374c22670ff9fd0d385ce366eb495/.github/workflows/test.yml#L199-L212

I created one here called "Release"

Thanks a lot for the example, I'll move forward in this direction and convert my script to use GitHub Actions.

[effigies]

@oesteban Can you make me an admin on the eddymotion PyPI package?

[esavary]

Is there a clever way to trigger the workflow for testing without pushing changes to the main branch?

[effigies]

Okay, looks like we can't do this from a fork, but it's mostly working.

We will need to adjust our version string, though: test.pypi.org will not accept local identifiers like the +gcc9a910 in 24.0.0.dev277+gcc9a910

[effigies]

I'm going to merge this. We can fiddle with versions and then resetting the run conditions in a PR from the main repo.