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

Skip building wheels if no release files have changed #10481

Merged
merged 1 commit into from Jul 28, 2020

Conversation

Eric-Arellano
Copy link
Contributor

The time we really need to run these jobs is when we're doing release prep, which means we will have changed notes/ and, sometimes, VERSION.

We also run the jobs if we've made changes to our release process.

As with Rust skips, developers can ignore this skip by manually changing their commit message.

Copy link
Member

@jsirois jsirois left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay!

@Eric-Arellano
Copy link
Contributor Author

Only test failure is the flaky test now skipped. Merging.

@Eric-Arellano Eric-Arellano merged commit f6ffe46 into pantsbuild:master Jul 28, 2020
@Eric-Arellano Eric-Arellano deleted the skip-wheels branch July 28, 2020 00:59
@benjyw
Copy link
Sponsor Contributor

benjyw commented Jul 28, 2020

So this actually means we can't easily run Pants at any SHA any more?

@Eric-Arellano
Copy link
Contributor Author

Eric-Arellano commented Jul 28, 2020

So this actually means we can't easily run Pants at any SHA any more?

Two possible remedies:

  1. Have the PR author leave off [ci skip-build-wheels] in the merge message to force building the wheels.
  2. Change the logic to always build on branch builds, no matter what.

Would #1 be sufficient? It would both reduce the CI backload and reduce our usage in S3 pretty dramatically.

@jsirois
Copy link
Member

jsirois commented Jul 28, 2020

So this actually means we can't easily run Pants at any SHA any more?

I think this was clarified on Slack, but "easily" is deceptive. Its easy to run pants from any sha, its just slow since the engoine needs to recompile. Is that right? So we're talking about speed inconvenience, not that its hard actually run pants without prebuilt wheels / pexes.

@benjyw
Copy link
Sponsor Contributor

benjyw commented Jul 28, 2020

So this actually means we can't easily run Pants at any SHA any more?

I think this was clarified on Slack, but "easily" is deceptive. Its easy to run pants from any sha, its just slow since the engoine needs to recompile. Is that right? So we're talking about speed inconvenience, not that its hard actually run pants without prebuilt wheels / pexes.

Yes, it's pretty much about scripting it up to make it straightforward to build pants and then use it in your repo, I guess.

@stuhood
Copy link
Sponsor Member

stuhood commented Jul 28, 2020

  1. Change the logic to always build on branch builds, no matter what.

This is what I thought would be happening here. We should continue to build+upload wheels for any branch/tag commits.

@benjyw
Copy link
Sponsor Contributor

benjyw commented Jul 28, 2020

  1. Change the logic to always build on branch builds, no matter what.

This is what I thought would be happening here. We should continue to build+upload wheels for any branch/tag commits.

Why?

@stuhood
Copy link
Sponsor Member

stuhood commented Jul 28, 2020

@benjyw : To allow for consuming them for testing using the infrastructure that you added yesterday. It's incredibly useful.

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.

None yet

4 participants