-
Notifications
You must be signed in to change notification settings - Fork 10
CI: Add removal of old uploads #12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI: Add removal of old uploads #12
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @matthewfeickert. If that's the same approach that Matplotlib has been using successfully, then all good to me.
The only thing to me is that, IIUC this is to be done per project right? On SciPy and NumPy at least, we are not using actions to do the upload but we rely on CirrusCI. So we would need to add another action that would not upload and just check for removal? (In practice we overwrite our upload and only have a single version. But other packages might do differently.)
Should we have a nightly action on this repo that would run this for all packages?
Ah I see that I have misunderstood what "centralise" meant in #4 (comment). @tupui so for SciPy and NumPy you use CirrusCI for all the uploads to https://anaconda.org/scientific-python-nightly-wheels? If so, then yes, this would all need to be a separate action and this PR should be closed. I think that it would be better to do a 1-action-per-repo policy, so in that case this PR should get closed and I could port the relevant logic to the new repo (I'm not very good at naming things so |
Let's continue the discussion on the issue before we make any decisions about closing etc. 😃 |
2577b71
to
56cd8fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given #4 (comment) please see these updated changes. I have tested this already on my fork with matplotlib
(c.f. the aside in #8 (comment) if wondering why I'm doing so) and things work as expected (which is good as I'm copying an existing workflow I wrote :P).
Agreed that querying the index for the list of packages would make this a bit more robust against future package additions. Aside, an alternative to
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @matthewfeickert 🚀 That's good on my side. Approving as the suggestion is optional to me for now.
56cd8fe
to
5fd637f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good on my side 🚀 thanks @matthewfeickert
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If left some minor bash styling feedback, but feel free to take it or leave it.
* Remove the workflow step for querying and removing all but the last 5 nightly wheel uploads to the scientific-python-nightly-wheels Anaconda Cloud package index as this is now centrally done by the Scientific Python org for all projects that upload to https://anaconda.org/scientific-python-nightly-wheels. - c.f. scientific-python/upload-nightly-action#12
5fd637f
to
d28e1de
Compare
1d24930
to
c121a1e
Compare
Thanks for the review @jarrodmillman! Does your approval mean that you were able to setup the |
c121a1e
to
85b99a0
Compare
* Add GitHub Actions workflow to remove old wheels from the package index each night at 1:23 UTC. Also allow for manual runs via workflow dispatch. * Remove all but the last N_LATEST_UPLOADS package version uploads to the package index to ensure space. To do this, reply on the output form of `anaconda show` to be able to filter on the item delimiter character sequence for each version currently uploaded. As an explicit example: ``` $ anaconda show scientific-python-nightly-wheels/xarray Using Anaconda API: https://api.anaconda.org Name: xarray Summary: Access: public Package Types: Standard Python Versions: + 2023.5.1.dev9+g609a9016 + 2023.5.1.dev10+gf45eb733 + 2023.5.1.dev11+gfcb81756 + 2023.5.1.dev12+gb319d867 + 2023.5.1.dev14+ge3db6164 To install this package with pypi run: pip install -i https://pypi.anaconda.org/scientific-python-nightly-wheels/simple xarray ``` shows that by filtering on '+' and then stripping ' + ' one can obtain a newline separated list of all package uploads, where the _most recent_ uploads are listed last. After stripping off the N_LATEST_UPLOADS lines that correspond to the package versions to keep for testing, the remaining (older) package uploads can be removed with `anaconda remove`.
* Use Dependabot to keep the GitHub Actions used in workflows up to date.
85b99a0
to
e964540
Compare
See #12 (comment) |
Thanks @matthewfeickert !!! |
Just did a manual run with workflow dispatch and all looks good!
Should be good to go for nightly cron jobs now and then just need to make sure that the workflow doesn't get shut off due to lack of repo activity. |
Awesome, thanks @matthewfeickert! I didn't realize inactive repos have their actions switched off. What do we need to do; a monthly empty commit? |
Yeah, from https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow
Though you will also get an email as a heads up and you can click a button in the email to keep the workflow alive. I'm also not 100% if "repository activity" means a Git operation or if it just means interaction with the repository in some way on GitHub. My assumption is that as we have Dependabot turned on this won't be an issue in general, but if it becomes one then we can also just have a GHA workflow that once a month checks out a |
It could also push a timestamp of its last run, maybe in a separate, empty branch, or gh-pages? |
Yup, but then you're accumulating a daily commit history on that other branch that still lives in the repo for no real reason. Is it easy to ignore? Sure, but seems kinda unnecessary. As you point out though, you could use Personally, I would put this problem in the "kick it down the road until it becomes a problem" bin, as for the multiple projects that I maintain that are are at this stage repos for LTS Docker images this hasn't come up much. Though if anyone has been nerdsniped by this conversation please go for it! 😉 |
I had repos where we run into this in practice, and wondered why the actions stopped working. So I would just like to avoid being on that road again :) |
One commit every 50 days on a |
Ahh, nice, thanks for the link. I was starting to hack something together, but it's probably much easier to just do the action. I'll open a PR for this. |
* Remove the workflow step for querying and removing all but the last 5 nightly wheel uploads to the scientific-python-nightly-wheels Anaconda Cloud package index as this is now centrally done by the Scientific Python org for all projects that upload to https://anaconda.org/scientific-python-nightly-wheels. - c.f. scientific-python/upload-nightly-action#12
Resolves #4
Remove all but the last
N_LATEST_UPLOADS
(defaulted to5
) package version uploads to the package index to ensure space. To do this, reply on the output form ofanaconda show
to be able to filter on the item delimiter character sequence for each version currently uploaded.As an explicit example:
shows that by filtering on
+
and then stripping
' + '
one can obtain a newline separated list of all package uploads, where the most recent uploads are listed last. After stripping off the
N_LATEST_UPLOADS
lines that correspond to the package versions to keep for testingthe remaining (older) package uploads can be removed with
anaconda remove
.Most of this is taken from matplotlib/matplotlib#23349 (c.f. #4 (comment)).
To provide a local reproducible example of the behavior,
curl
the following attached Shell script into acontinuumio/miniconda3:latest
container withanaconda-client
installedexample-pr-12.sh:
example-pr-12.sh.txt
I'm marking this as closing Issue #4 despite that it doesn't include a time cutoff as described in #4 (comment) given that I do not know of a
pip
oranaconda-client
API that gets upload date information from the index (Probably exists somewhere though?) and this PR resolves all other matters as far as I understand it. We can revise or extend this if desired.