Recommend best practices for continuous integration:
1 Like
This is coming out of our sprint at the 2022 NumFocus summit.
Idea for Actions:
- Recommend project to understand security risks and guard against them when possible. See Security hardening for GitHub Actions - GitHub Docs
- Use hash of release over tag name because the latter can be silently overwritten. Though maybe tag name is acceptable if your Action is from a very reputable source?
1 Like
Re: Nightly jobs – I would go a step further and recommend you run it for all PRs but allow it to fail to make sure changes are forward-compatible (e.g., not using a feature that has been dropped in unreleased upstream code). Allowing it to fail will not block PRs if the failure is unrelated to the PR changes (since dev is unstable by definition). Maintainers do have to do the due diligence to check it even though it is allowed to fail or this will not accomplish its purpose.
1 Like
Hi all, thanks for the really important work you’re doing here.
@dopplershift @jarrodmillman is there more discussion I can read somewhere to understand the context for this SPEC?
Something like what @matthewfeickert provides here
Interest in GitHub Action for scipy-wheels-nightly uploads and removals for SPEC 004?
I went to the links but they just have recommendations and then they link back here.
2 Likes
This is a placeholder from a BoF at the recent NumFOCUS project summit. I have additional details, but I haven’t had a chance to write things down yet. I should have time this weekend or early next week. But there will still be a lot to discuss and work out for this SPEC. I will comment here once I’ve added some additional details from our discussion.
Understood, thank you @jarrodmillman!
I guess I’m not clear on the process yet – I thought “draft” meant it was already accepted?
Just want to make sure I can understand and relay what you all are doing
I will remain calm 
and look forward to the discussion.
1 Like