Hi, For me, the best you can do to avoid this kind of problem is to avoid committing directly into the target branch by always submitting a PR for any change. And then, once the build is green, merge the PR with "Squash and merge" which is the default action on Camel. The action "Rebase and merge" should be avoided since the build result reflects the final state of the branch, not the intermediate states. In case you need some changes to fix the build, make sure to re-synchronize the source branch with the target branch, especially in case the changes are not done on the same day because the Camel branches are modified very frequently and each change can potentially be in conflicts with yours.
it is a quite cumbersome approach but I don't see any safer way. Regards, Nicolas ________________________________ From: Otavio Rodolfo Piske <angusyo...@gmail.com> Sent: Thursday, June 22, 2023 08:53 To: dev@camel.apache.org <dev@camel.apache.org> Subject: Re: Some thoughts on bisecting Camel and our git commit practices Hi, Release-tagged commits don't help here. The whole point of bisecting is finding out precisely which commit introduced a certain behavior or bug, so that I and other committers can diagnose, document and fix the problem. It's not possible to do that effectively with just release-tagged commits. Also, I don't think each commit needs to be "release quality": that would be too much right now. I do think, however, that each commit should be compilable. Consider, for instance, the following commit pattern I notice when bisecting the code: commit1: TASK111: did some stuff ---> not compilable commit2: TASK111: did some stuff ---> compilable commit3: TASK111: did some stuff ---> not compilable commit4: TASK111: did some stuff ---> compilable Git bisect run is smart enough to skip commit2 and commit3 if given a proper exit code (that's what we do). However, the problem gets worse once these compilable scripts start to pile up, such as: commit1: TASK111: did some stuff ---> not compilable commit2: TASK111: did some stuff ---> compilable commit3: TASK111: did some stuff ---> not compilable commit4: TASK111: did some stuff ---> compilable commit5: TASK222: did some stuff ---> not compilable commit6: TASK222: did some stuff ---> compilable commit7: TASK222: did some stuff ---> not compilable commit8: TASK222: did some stuff ---> compilable At some point, the bisect execution runs out of skippable commits and you have to: a) test manually, b) restart the bisect operation with different good/bad commits, or c) investigate the list of skipped commits one by one. The same can happen when merging community contributions composed of multiple commits. So, I think we can improve here by doing 2 things: 1. When commiting the work on a task, making sure that every commit is compilable. For instance, in the pattern above, by squashing commit1+commit2, commit3+4, etc. 2. When merging community contributions with multiple PRs, squashing the contribution before merging - if suspicious that one or more of the commits introduce uncompilable changes. If we start doing this now, bisecting will be much easier in the future. Kind regards On Thu, Jun 22, 2023 at 8:08 AM Petr Kuzel <petrku...@eurofins.com.invalid> wrote: > Hi Otavio, > > the codebase does not have the release quality > after each commit. Test-driven development could > even invite devs to separately commit failing tests > as a proof they are effective. > > On contrary the release-tagged commits should > be safe. Would not help you to focus > on the release-tagged commits only, pls? > Hope it helps > Cc. > > -- > Mr. Petr Kužel, Software Engineer > Eurofins International Support Services s.à r.l. > Val Fleuri 23 > L-1526 LUXEMBOURG > > -----Original Message----- > From: Otavio Rodolfo Piske <angusyo...@gmail.com> > Sent: Wednesday, June 21, 2023 11:17 > To: dev <dev@camel.apache.org> > Subject: Some thoughts on bisecting Camel and our git commit practices > > > Folks, > > You may have seen that PRs constantly report failures when testing changes > on core. This is almost always caused by flaky tests. > > I have been trying to find the root causes of those flaky tests. Quite > often this involves going all the way to early versions of Camel 3 to find > stable executions of those tests. > > The investigation itself is mostly automated by using git bisect run ... > This significantly improves the developer ability to find the root causes > of issues. > > Despite all this automation, however, the task has been ... quite difficult > and lengthy. Even considering the extensive resources I have access to > (thanks to my employer), bisecting a single test failure can take several > *days*. > > In particular, this investigation has been difficult because we have a huge > amount of dirty commits on the tree: partially modified work, uncompilable > changes, broken tests and more. > > While it's NOT my intention to suggest introducing/discussing a full blown > clean commit policy, I do wonder if we have some room to discuss how we can > improve the way we work to ensure that the tree is compilable and somewhat > testable (and, possibly, enforce that). > > We cannot fix the git history of the project, but we can ensure that future > investigation can be made much easier in the future. > > So, folks, does anyone have any suggestions about how we could improve > here? > > Kind regards > -- > Otavio R. Piske > https://urldefense.com/v3/__http://orpiske.net/__;!!CiXD_PY!SZvpton5vuSh5elDATUqZmerIhuL7ZGmoTwQB-66e3u34QRJzR2DoTvCjF3miU2oF4glDqKC5VnT439E0B0$ > -- Otavio R. Piske https://urldefense.com/v3/__http://orpiske.net__;!!CiXD_PY!SZvpton5vuSh5elDATUqZmerIhuL7ZGmoTwQB-66e3u34QRJzR2DoTvCjF3miU2oF4glDqKC5VnTh1-lNIM$ As a recipient of an email from the Talend Group, your personal data will be processed by our systems. Please see our Privacy Notice <https://www.talend.com/privacy-policy/> for more information about our collection and use of your personal information, our security practices, and your data protection rights, including any rights you may have to object to automated-decision making or profiling we use to analyze support or marketing related communications. To manage or discontinue promotional communications, use the communication preferences portal<https://info.talend.com/emailpreferencesen.html>. To exercise your data protection rights, use the privacy request form<https://talend.my.onetrust.com/webform/ef906c5a-de41-4ea0-ba73-96c079cdd15a/b191c71d-f3cb-4a42-9815-0c3ca021704cl>. Contact us here <https://www.talend.com/contact/> or by mail to either of our co-headquarters: Talend, Inc.: 400 South El Camino Real, Ste 1400, San Mateo, CA 94402; Talend SAS: 5/7 rue Salomon De Rothschild, 92150 Suresnes, France
