search

scientific-python / upload-nightly-action

This action is used to upload nightly builds of your package.
https://anaconda.org/scientific-python-nightly-wheels
BSD 3-Clause "New" or "Revised" License
7 stars 10 forks source link

Make Remove Old Wheels workflow seperate GitHub Action #62

Open matthewfeickert opened 9 months ago

matthewfeickert commented 9 months ago

As we're getting requests from different libraries to be added (Issues #29, #45, #50) and recommending to those groups to instead make their own Anaconda Cloud org and use the 0.3.0 release of the action to upload to their own org (https://github.com/scientific-python/upload-nightly-action/pull/47#issuecomment-1908716794, https://github.com/scikit-hep/awkward/issues/3011) it would be nice to also not have these teams have to reimpliment their own space saving workflow.

It would be easy to turn the "Remove old wheels" workflow into a YAML only (no Docker needed) GitHub Action to pair with the upload-nightly-action.

Thoughts?

stefanv commented 9 months ago

I think anything we can do to make their life easier is great.

bsipocz commented 9 months ago

Totally reasonable proposal, and I'm happy to do the refactoring or review PRs for it!

agriyakhetarpal commented 8 months ago

Hi! I'm willing to help out by writing a PR for this, but I would love some pointers as to how to start – one of the reasons why I ask this is because isn't it easy for someone to run a workflow from a file, i.e., just run https://github.com/scientific-python/upload-nightly-action/blob/main/.github/workflows/remove-wheels.yml inside another workflow? i.e., something like:

- name: Delete older wheel uploads
  uses: scientific-python/upload-nightly-action/.github/workflows/remove-wheels.yml@main

or is the plan to publish two separate workflows per release so that they can be called with scientific-python/upload-nightly-action/remove-wheels@vX.Y.Z? I am an avid user of GitHub Actions and I'm pretty familiar with the syntax by now – but it would be the first time writing one myself :) I did glance at the code briefly – I assume what one needs to do is to provide things as N_LATEST_UPLOADS and ANACONDA_USER as configurable inputs to the step above (with with:) where the workflow will be used (also, it might make sense to map these environment variables to the context of a specific step where their use is invoked instead of the entire job). I would be happy to receive further clarifications (and add this feature, if you don't intend to work on it at this time, that is, @bsipocz – please let me know!).