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

ci: don't run on push #122

Merged
merged 1 commit into from
Feb 18, 2024
Merged

ci: don't run on push #122

merged 1 commit into from
Feb 18, 2024

Conversation

dundargoc
Copy link
Member

There's no real reason to run on push as we're not using any caching.

There's no real reason to run on push as we're not using any caching.
@clason clason merged commit d1369fc into neovim:master Feb 18, 2024
1 check passed
@dundargoc dundargoc deleted the ci branch February 18, 2024 20:19
@justinmk
Copy link
Member

It's good to save CI time, but for low-activity repos I think we should err on the side of explicitness.

Reasons in favor of CI on push:

  • to have a baseline, so one can see the history of status checks by looking at master (including squash-merged PRs)
  • for any (rare) commits that skip the PR process

Without this, we don't have a clear concept of "current status", except whatever the last PR was (which also assumes a linear history).

dundargoc added a commit to dundargoc/tree-sitter-vimdoc that referenced this pull request Feb 18, 2024
This reverts commit d1369fc.

The reasoning is provided by @justinmk in
neovim#122 (comment):

It's good to save CI time, but for low-activity repos I think we should
err on the side of explicitness.

Reasons in favor of CI on push:
  - to have a baseline, so one can see the history of status checks by looking at master (including squash-merged PRs)
  - for any (rare) commits that skip the PR process

Without this, we don't have a clear concept of "current status", except
whatever the last PR was (which also assumes a linear history).
@dundargoc
Copy link
Member Author

Yeah, that's a fair point. I was mostly focused on reducing CI time for the organization but having it run on master is probably more valuable like you said. I've reverted it in #123

clason pushed a commit that referenced this pull request Feb 18, 2024
This reverts commit d1369fc.

The reasoning is provided by @justinmk in
#122 (comment):

It's good to save CI time, but for low-activity repos I think we should
err on the side of explicitness.

Reasons in favor of CI on push:
  - to have a baseline, so one can see the history of status checks by looking at master (including squash-merged PRs)
  - for any (rare) commits that skip the PR process

Without this, we don't have a clear concept of "current status", except
whatever the last PR was (which also assumes a linear history).
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.

3 participants