Skip to content

Make Remove Old Wheels workflow seperate GitHub Action #62

Open

Description

@matthewfeickert

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 (#47 (comment), scikit-hep/awkward#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?

Activity

  1. stefanv commented on Feb 8, 2024

    @stefanv
    Member

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

  2. bsipocz commented on Feb 8, 2024

    @bsipocz
    Member

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

  3. agriyakhetarpal commented on Mar 22, 2024

    @agriyakhetarpal
    Member

    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!).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions