3 ms·

GH processes at the commit level for things (including actions) even though they're bundled in a push... it's relevant to the load on their infrastructure.

ferngodfather 3mo ago
But they can't process the commit until I push it?
- dcrazy 3mo ago
  A push containing 100 commits is more expensive than a push containing 1 commit.
  - blitzar 3mo ago
    But is it 100x more expensive?
    - Groxx 3mo ago
      Probably? If you do 100 pushes instead, there is roughly zero additional data. At best you'd be comparing cache costs, which probably are lper for one large push, but there's a ton of calculation and CI that runs per commit regardless of other data being cached.
      - lukevp 3mo ago
        Why don’t you have your actions run on pr or push instead of on commit? Why would you even want that? I’ve never seen actions set up that way. If I push a branch with 100 commits then it’ll only run CI once. It’ll show the rest of the commits in the UI, sure, but that doesn’t mean that it’s the same performance impact. It could very well be 1 db transaction with multiple rows written instead of 100. I think you’re reducing this problem too much without knowing their architecture.
        Groxx 3mo ago
        Github runs CI per PR push (obviously), and per main-branch commit (click on commit history in any project with CI, see a build result check mark on each one - that's true if you push a dozen commits too (I've done that)), in nearly all setups I've seen. I'm not sure how much of that is required vs default though. With enough effort, you can rather obviously run CI per PR commit (it's a programmable system), but I've never seen aUI-integrated way to track the results, aside from browsing custom job names, which is very far from what I'd call "integrated" when compared to PR-level build markers. Similarly, I'm not aware of (but would not be surprised by) any way to disable per-main-branch commit builds, aside from initial pushes. But I haven't poked around deeply in the settings, and business-account settings are rather different anyway so those might be wildly different / more flexible / more obtuse in exciting ways. Github is a very large and complicated product at this point, darn near anything could exist if you dive through enough UI layers or use old URLs to find soft-deprecated features. Also, honestly, 100 commits = 1 transaction? That's far more of an over-simplification than anything I've said. It's a massive product with thousands of engineers, there's no chance at all it's just one database.
        richardwhiuk 3mo ago
        Things like password scanning have to look per object uploaded
_heimdall 3mo ago
In what way? If I have multiple local commits pushed once I expect to see CI type actions to run once for the push rather than for ever commit in the push.
- TorKlingberg 3mo ago
  This is configurable in Github Actions. Many projects want to run CI for each commit to avoid situations where one commit breaks the build and the commit after in the same push or PR fixes it. Broken commits in the history makes bisecting harder.
  - _heimdall 3mo ago
    Interesting, never realized that was an option. Thanks!

ferngodfather 3mo ago

But they can't process the commit until I push it?

dcrazy 3mo ago
A push containing 100 commits is more expensive than a push containing 1 commit.
- blitzar 3mo ago
  But is it 100x more expensive?
  - Groxx 3mo ago
    Probably? If you do 100 pushes instead, there is roughly zero additional data. At best you'd be comparing cache costs, which probably are lper for one large push, but there's a ton of calculation and CI that runs per commit regardless of other data being cached.
    - lukevp 3mo ago
      Why don’t you have your actions run on pr or push instead of on commit? Why would you even want that? I’ve never seen actions set up that way. If I push a branch with 100 commits then it’ll only run CI once. It’ll show the rest of the commits in the UI, sure, but that doesn’t mean that it’s the same performance impact. It could very well be 1 db transaction with multiple rows written instead of 100. I think you’re reducing this problem too much without knowing their architecture.
      - Groxx 3mo ago
        Github runs CI per PR push (obviously), and per main-branch commit (click on commit history in any project with CI, see a build result check mark on each one - that's true if you push a dozen commits too (I've done that)), in nearly all setups I've seen. I'm not sure how much of that is required vs default though. With enough effort, you can rather obviously run CI per PR commit (it's a programmable system), but I've never seen aUI-integrated way to track the results, aside from browsing custom job names, which is very far from what I'd call "integrated" when compared to PR-level build markers. Similarly, I'm not aware of (but would not be surprised by) any way to disable per-main-branch commit builds, aside from initial pushes. But I haven't poked around deeply in the settings, and business-account settings are rather different anyway so those might be wildly different / more flexible / more obtuse in exciting ways. Github is a very large and complicated product at this point, darn near anything could exist if you dive through enough UI layers or use old URLs to find soft-deprecated features. Also, honestly, 100 commits = 1 transaction? That's far more of an over-simplification than anything I've said. It's a massive product with thousands of engineers, there's no chance at all it's just one database.
        richardwhiuk 3mo ago
        Things like password scanning have to look per object uploaded

_heimdall 3mo ago

In what way? If I have multiple local commits pushed once I expect to see CI type actions to run once for the push rather than for ever commit in the push.

TorKlingberg 3mo ago
This is configurable in Github Actions. Many projects want to run CI for each commit to avoid situations where one commit breaks the build and the commit after in the same push or PR fixes it. Broken commits in the history makes bisecting harder.
- _heimdall 3mo ago
  Interesting, never realized that was an option. Thanks!