[WIP]: Add a separate action for removing old wheels

[agriyakhetarpal]

Description

Tip

This is a draft PR at the time of writing, and the description is a stub – it shall be updated soon. However, reviews on the approach are welcome!

This PR closes #62; by converting the .github/workflows/remove-wheels.yml workflow to a composite action in remove-wheels/action.yml that users can trigger in their workflows separately to delete binaries uploaded to the https://anaconda.org/scientific-python-nightly-wheels/ index or other Anaconda.org indices.

This way, users should be able to add, for example:

- name: Remove old wheels
  uses: scientific-python/upload-nightly-action/[email protected] # or, better, via the commit hash
  with:
    anaconda_token: ${{ secrets.ANACONDA_NIGHTLY_UPLOAD_TOKEN }} # same as that for uploads (convenience?)
    # Optionally override defaults:
    # n_latest_uploads: '5'
    # anaconda_user: 'my-custom-org'

or similar variations, to delete any but the last five wheel uploads, which means that this repository does not need to do so and can delegate this responsibility to the workflow files for the twenty-six packages listed under the https://anaconda.org/scientific-python-nightly-wheels/repo page.

Changes made

To be updated

Checklist

• Resolve the to-do items (some of them have been marked as inline comments in the code for now)
• Add relevant documentation, and adjust headings in the README
• If .github/workflows/remove-wheels.yml stays, figure out how to not unintentionally delete wheels without the existence of packages-ignore-from-cleanup.txt

---

I've been meaning to do this for some time now, and I didn't receive a response to #62 (comment) back then. However, since it was mentioned that PRs would be welcome for reviews, and the repository has recently received quite a few updates (and a new release! 🎉), so I finally spent thirty minutes of my time writing this out—mostly just adding the script to a separate file—wherein I've added the necessary scaffolding around its creation as a separate, distributable action.

[agriyakhetarpal]

Okay, I've just read some discussion(s) on keeping the removal of old wheels "centralised" in #4 (comment) and in the comments after it. Those made sense to me, so, this PR could be considered in conjunction with that policy – to let SPNW clean up old wheels itself, and let these changes be a "refactor" of the wheel removal logic in a sense, i.e., from being embedded in a workflow to a separate action that gets used in it. This would also ease the removal process around those who want to take up the responsibility of removing their wheels that have been uploaded outside SPNW-managed Anaconda.org indices. It is to be noted that that discussion predates the ones linked in #62, so it is likely the case that requests for easier removals have arisen in more contexts by now.

[bsipocz]

Yes, having the cleanup parts moved to a new action and then using it sounds to be the right way to go, that way we expose the functionality for easy reuse while we also keep using it.

[matthewfeickert]

I am in transit and won't have time to review or give feedback on this for a few days. My original intent in Issue #62 was to make a new repository and have that action be totally independent of this repository. Though, we can certainly get this in here and then just move it elsewhere later if people agree that's a good idea.

[agriyakhetarpal]

That sounds great! Thanks for triggering the workflow for me – I shall revisit this either later in the day or early next week. That said, I don't think one can run the workflow from forks, though... I have an account on Anaconda.org already since I'm helping manage the PyWavelets wheels (#75), should I add a dummy package for testing (in my account, that is)?

[agriyakhetarpal]

to make a new repository and have that action be totally independent of this repository. Though, we can certainly get this in here and then just move it elsewhere later if people agree that's a good idea.

Personally, I would say that related actions like these ones could be grouped together just fine, since one repository is easier to manage, rather than two – easier permissions to deal with, unified documentation in the README, unified dependency management (using pixi), etc., so this could fit in the same repository very well. For example, https://github.com/github/codeql-action contains six actions, with each managed in its own folder.

Of course, this is just my opinion, so I'm happy to implement whatever works best within the community.