On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy <ohadl...@gmail.com> wrote: > Hi, > > The challenge: > > As a developer, I feel under utilized waiting for tests, the current test > suite for foreman core takes over an hour, multiply it by number of really > simple code fixes based on comment and it takes up a good chunk of a day.
Personally, I don't feel this issue: if it's 1 hour or 5 minutes: I'm already doing something else in the meantime, so I would not probably see much the difference. Locally, I usually run just the test file that touches the code I'm working on to have the immediate feedback on those. Waiting a bit longer on the PR is a price I'm willing to pay for increasing the chance that my code runs as much as possible. > > I would like to suggest a short and long term solution, and would appreciate > your feedback. > > Short-term: > > Break down test matrix into more specific groups, this will allow to > re-trigger just a smaller part of the tests vs. the entire suit today, for > example: > * API tests > * DB migrations > * UI Integration tests > * ... Not opposed. Seems like valid request. > > Long term: > > Break down core into smaller repositories - This is probably a bigger topic > then just tests, but its worth raising in this context as well.. the > benefits i see are: The question: would this speed-up the things moving, in terms of getting changes in? I would worry that the outcome would be just oposite of that. > > * smaller repos - faster tests per repo (we would still need a plugin matrix > kind of tests done at some point) We should solve the pluign matrix first, ideally on PR level: I would recommend first mastering that before going with more split. > * better review process - smaller repos would mean the maintainers of the > repo actually care for all/most of the pr's - today its not the case - many > PR's are handled by sub groups (e.g. anything under webpack folder is > "someone else") But still, most of the reviewers at least see, what's going on there. I know we could achieve this with more repos as well, but frankly, not sure it would work that much in the real life. > * potentially better API between parts - e.g. we can create a schema > specific repo (not saying its a good idea) - which will always work with a > dummy rails app - in the long run - this will ensure our schema is resilient > to upgrades and model changes in core. I miss the implication. Could you expand on the thoughts? > > I would even go further and enable auto merge after review + successful > tests, e.g. > 1. PR is sent > 2. repo tests are executed and pass > 3. reviewer approve the change > 4. larger test matrix is executed and pass > 5. code get auto merged. This is ortogonal to any of the previous and makes sense to me. -- Ivan > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
