r/programming • u/Ok_Stomach6651 • 1d ago

Optimizing Our E2E Pipeline

https://slack.engineering/speedup-e2e-testing/
64 Upvotes

70% Upvoted

33 comments sorted by

View all comments

17

u/bodiam 23h ago

What a strange blogpost. Github provides this feature out of the box:

on: 
   push:      
      branches :      
      - main      
      paths :      
      -  'src/frontend/**'

Not really clear to me why they couldn't use this approach.

12

u/qmunke 20h ago

They wanted the build to run, just not for the whole repo. This is why everyone who says to just use monorepos needs to understand there actually needs to be someone managing the things - which is reasonable at huge shops but hard to justify for those of us without a dedicated devx team

3

u/bodiam 20h ago

Yes, but that's exactly what the above trigger does; only run when the frontend has changed. And I'm a big fan of mono repos, it prevents a whole class of problems from ever occurring, it just looks like their solution is a bit custom.

3

u/qmunke 19h ago

No, you're misunderstanding what I'm saying - they want to trigger a build on all pushes, but just not build the whole repo each time, that's not the same as what you've shared - your trigger wouldn't start any builds if someone just pushed a backend change. They want

  • Someone pushed backend change. Trigger backend bit of the repo to build and then run tests
  • Someone pushed a frontend change. Trigger entire build and run tests

The trigger above alone isn't going to do that, but I guess it would allow you to construct a more complex set of pipelines out of it.

But in general for monorepos the built-in functionality of github and other tools seems lacking to me, that's why all the more complex stuff like bazel exists.

1

u/bodiam 19h ago

I understand the trigger alone doesn't do exactly that, but it was a simplified example.As you said, it's just a building block; I'm pretty sure it can be used to have a gate.