On úterý 7. listopadu 2017 11:12:31 CET Ivan Necas wrote: > On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy <[email protected]> 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 don't think it's any issue for me either. > > > 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. +1 > > 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. I don't like the idea. My ceoncern is we'd have more repos without reviews. > > > * 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. Good idea -- Marek -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
