0123456789ABCDE

11 ms·

1. 181.▲
   by 0123456789ABCDE 1y ago

   if you want to reuse the local setup for ci or pushing broken code is somehow undesirable, then run all the tests pre-push i tend to run only the fast set of tests, or a subset of the environments matrix, on pre-push — CI can take care of t
2. 182.▲
   by 0123456789ABCDE 1y ago

   i don't know what you think i care about, when i run the auto-formatter on file-save, if not for the formatting of the code
3. 183.▲
   by 0123456789ABCDE 1y ago

   > but you definitely want a thorough test suite to run occasionally. that's what ci is for anyway, if you're doing embedded development and can distinguish between different kinds of testing then my previous post is not meant f
4. 184.▲
   by 0123456789ABCDE 1y ago

   your ci setup should take care of the slow tests — for most folks this is github actions pre-push can run the faster unittest set, ci will run the integration set aim to keep pre-push duration under 10s
5. 185.▲
   by 0123456789ABCDE 1y ago

   it's the tools. if they're slow people disable them or shift them right. you want your defect-detection and fixing to shift left if you're not running auto-format on file-save, your auto-formatter is slow if you're not r