Align development requirements with Tidelift's Security-advised PyPI catalog #5762
Comments
|
Done, pending merge of #5763 |
|
https://support.tidelift.com/hc/en-us/articles/4406286154004 says of the type:
The screenshot shows only runtime, but these are all for development (maybe excepting olefile, which is an optional dependency, but must be installed separately and we only install for testing). Is there a way to mark them as development? |
|
@hugovk I haven't considered doing it for runtime yet because to create a project on Tidelift, we need a |
Off the top of my head we don't have any required runtime dependencies (only optional).
What is the action actually doing? Gathering stats for the catalogue? When do we want it to run? Is it something that should fail a PR if something needs doing? Or just need to run it occasionally, like when something is pushed to https://support.tidelift.com/hc/en-us/articles/4406286307220-Using-with-Continuous-Integration suggests every PR:
What sort of failures can we expect, what action would I as a developer need to take if something failed? |
|
Maybe @JeffStern can help ^ with my questions :) @aclark4life Maybe let's revert the action for now and put it in the PR as well? To make sure it's running properly and is also skipped for forks (i.e. avoid this https://github.com/hugovk/Pillow/actions/runs/1343212315). I'd especially like things running smoothly for tomorrow's release :) Starting tomorrow morning, Europe time. |
|
@hugovk Sure go ahead |
20 tasks
Here is some output from a Jenkins running at my house to build a catalog. That job runs this That target updates the requirements then calls
In building a catalog, once a day to "keep up" with ever-evolving ecosystem. In using a catalog … in our case … probably still once a day because this is experimental and the value add is TBD. I expect little benefit in Pillow's case, but I'd still like to see it running here to support Tidelift's efforts of opening up catalogs to lifters for the potential value to other projects.
Good question! In building a catalog I've seen very few failures, if any. In using a catalog, assuming the Tidelift API answers the phone, then we should just expect to occassionally see results like "Your SBOM not aligned with our catalog!" In the case of our development requirements, we don't specify any versions so in theory, our requirements will always be 100% aligned with the security-advised PyPI catalog. |
|
Thanks for checking all that! So it sounds like we're fine running it daily and don't need to trigger it with regular PRs, at least initially. I'd suggest something like this at the top of on:
schedule:
- cron: "30 2 * * *" # daily at 02:30 UTC
push:
paths:
- ".github/workflows/tidelift.yml"
pull_request:
paths:
- ".github/workflows/tidelift.yml"
workflow_dispatch:
Also it looks like we're missing an API key: https://github.com/python-pillow/Pillow/runs/4124628947?check_suite_focus=true Please can you create one and store it in the repo secret settings as |
|
@hugovk I'll let @JeffStern answer about giving Pillow team members access to Tidelift dashboard, but in the meantime let's assume the failures are sphinx and babel not available in the catalog. Where does babel even come from? I just ran I'm tempted to remove all the package names and start adding them back one by one … |
|
Done in #5763 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FYI I'm going to be setting up a GitHub Action for Tidelift for this:
In the Tidelift parlance, we're going to make sure our development environment "aligns with Security-advised PyPI catalog". While it's obviously not critical that folks use the latest docutils to develop Pillow, it may be interesting to be able to say our development requirements "meet certain licensing, security or other standards". If nothing else, it will definitely help Tidelift as they try to improve "how lifters work with Tidelift and their subscribers". 👍
The text was updated successfully, but these errors were encountered: