Skip to content
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

Revise pip.yml to produce true nightlies #7397

Closed
wants to merge 3 commits into from
Closed

Conversation

steven-johnson
Copy link
Contributor

Instead of trying to produce new package(s) for every commit (which sometimes happens multiple times per day), it seems more reasonable (and less confusing) to produce nightlies instead. This PR is configured to trigger every night at 8:15 PST.

Note that both the current status quo, and this PR, have a nontrivial defect that is hard to fix: they need to build against an LLVM image that we have in a Docker image; for release branches, that's a relatively fixed target, but for top-of-tree Halide, it really should be a working snapshot of top-of-tree LLVM. (At the time of this PR, Halide main should really have nightlies built against LLVM 17.x work-in-progress, but this PR builds against LLVM 15.0.7 because it's the most recent thing we have available. This is highly suboptimal.)

Instead of trying to produce new package(s) for every commit (which sometimes happens multiple times per day), it seems more reasonable (and less confusing) to produce nightlies instead. This PR is configured to trigger every night at 8:15 PST.

Note that both the current status quo, and this PR, have a nontrivial defect that is hard to fix: they need to build against an LLVM image that we have in a Docker image; for release branches, that's a relatively fixed target, but for top-of-tree Halide, it really should be a working  snapshot of top-of-tree LLVM. (At the time of this PR, Halide main should really have nightlies built against LLVM 17.x work-in-progress, but this PR builds against LLVM 15.0.7 because it's the most recent thing we have available. This is highly suboptimal.)
@alexreinking
Copy link
Member

We probably want to go for every commit on release branches and for PRs to release branches.

We also want to run the real deal when a release is created.

@steven-johnson
Copy link
Contributor Author

We probably want to go for every commit on release branches and for PRs to release branches.

We also want to run the real deal when a release is created.

Agreed.

@steven-johnson
Copy link
Contributor Author

This has been sitting out here so long I forget where it stands.

@alexreinking
Copy link
Member

This has been superseded by #8405 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants