ci: reduce push triggering ci actions to just develop and master

[BenTopping]

Changes proposed in this pull request

• Reduces ci test actions running on push to just master and develop

[StephenHulme]

I would suggest leaving Limber as is? It runs many fewer tests than sequencescape, for a shorter time - meaning that it doesn't block the runners nearly as much?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.99%. Comparing base (069cce4) to head (f59c3b9).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #2795   +/-   ##
========================================
  Coverage    84.99%   84.99%           
========================================
  Files          504      504           
  Lines        20668    20668           
  Branches       377      377           
========================================
  Hits         17566    17566           
  Misses        3099     3099           
  Partials         3        3           

Flag	Coverage Δ
javascript	80.25% <ø> (ø)
pull_request	84.99% <ø> (ø)
push	?
ruby	92.62% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[BenTopping]

I would suggest leaving Limber as is? It runs many fewer tests than sequencescape, for a shorter time - meaning that it doesn't block the runners nearly as much?

I think this still has value by reducing redundant compute / actions. The push actions and pull request are running the same tests (except pull request is based on the merge with the base) so I dont see the need to run both.

[StephenHulme]

I would suggest leaving Limber as is? It runs many fewer tests than sequencescape, for a shorter time - meaning that it doesn't block the runners nearly as much?

I think this still has value by reducing redundant compute / actions. The push actions and pull request are running the same tests (except pull request is based on the merge with the base) so I dont see the need to run both.

I wouldn't agree that they are redudant, in that they provide different information. A PR can pass for the push but fail for the pull_request if there are incompatible changes already in develop`. This particular bit of knowledge can help debug subtle problems arising from multiple people working on the repo simulatenously.

I'm happy to be overriden on this, but may I suggest we trial with the Sequencescape changes already merged in and see how it goes?
It's worth noting that we have 20 runners. One push on Sequencescape can use all of them for at least 4 minutes. Whereas Limber only has two tests that run longer than a minute, leaving much spare capacity.

[BenTopping]

I would suggest leaving Limber as is? It runs many fewer tests than sequencescape, for a shorter time - meaning that it doesn't block the runners nearly as much?

I think this still has value by reducing redundant compute / actions. The push actions and pull request are running the same tests (except pull request is based on the merge with the base) so I dont see the need to run both.

I wouldn't agree that they are redudant, in that they provide different information. A PR can pass for the push but fail for the pull_request if there are incompatible changes already in develop`. This particular bit of knowledge can help debug subtle problems arising from multiple people working on the repo simulatenously.

I'm happy to be overriden on this, but may I suggest we trial with the Sequencescape changes already merged in and see how it goes? It's worth noting that we have 20 runners. One push on Sequencescape can use all of them for at least 4 minutes. Whereas Limber only has two tests that run longer than a minute, leaving much spare capacity.

Okay thats makes sense. The counter argument to that is that we should always be update to date with the base when getting ready to merge which would make pull and push the same. Happy to trial the SS one and see how it goes.