Yeah, again, I’m not against, I just wanted to mention that it already works (even not optimal) ;)
Regards JB > Le 9 févr. 2021 à 15:58, Mohamed-Tayeb BENTERKI <[email protected]> a écrit : > > Hi, > > Yes, currently we also have the Jenkinsfile and it's triggered at every PR, > but there are sometimes painful points, such as the fact that the execution > time is too slow and doesn't synchronise well with Github, and I understand > your point of view, IMHO, I think the move to GHA will have advantages and > won't break anything. > > Thank you > > On Tue, Feb 9, 2021 at 3:36 PM Jean-Baptiste Onofre <[email protected]> wrote: > >> Hi, >> >> Just to let you know that we can already do that with Jenkins: it’s what >> we do at Karaf with Jenkinsfile: we have a build on each PR/each commit. >> >> That was my question: Unomi could directly use the same approach as in >> Karaf, even using Jenkinsfile and pipeline. >> >> Again, don’t get me wrong: I’m not against moving to GHA, I just say that >> we can already have the features using Jenkinsfile. >> >> Regards >> JB >> >>> Le 9 févr. 2021 à 15:16, Taybou BENTERKI <[email protected]> a écrit >> : >>> >>> Hello, >>> >>> Thank you for the feedback JB, much appreciated >>> >>> I guess that by development process you mean the fact that GHA can work >> on >>> fork, right ? >>>> I mean that every time a new PR is opened, the GHA is triggered and we >>> can see the result of exclusion from the workflow at one place (Github) >>> >>> I don’t see why GHA would improve releases quality comparing to Jenkins >>> (they execute the same mvn build). >>>> Validating the execution of workflows, i.e. building, testing and >>> integration tests that are really fast and stable, means that we are more >>> sure that no regression has been introduced and that we limit the time >> for >>> manual testing before release, which is why I said improving the quality >> of >>> releases, but I agree with you when we compare with Jenkins, they run the >>> same workflows, which makes the migration to GHA relatively simple. >>> >>> So, what’s your arguments (other than managed service) for GHA compared >> to >>> Jenkins ? >>>> Fast, centralised and more UI friendly (we stay in Github) >>> >>> Looking forward to hearing from you >>> Thank you again >>> >>> On Tue, Feb 9, 2021 at 2:18 PM Jean-Baptiste Onofre <[email protected]> >> wrote: >>> >>>> Hi, >>>> >>>> No problem for me, but be careful, some Apache projects are complaining >>>> about the number of GitHub Actions jobs started (it’s the case at least >> on >>>> Beam and Airflow). >>>> >>>> I guess that by development process you mean the fact that GHA can work >> on >>>> fork, right ? >>>> >>>> I don’t see why GHA would improve releases quality comparing to Jenkins >>>> (they execute the same mvn build). >>>> >>>> So, what’s your arguments (other than managed service) for GHA compared >> to >>>> Jenkins ? >>>> >>>> Regards >>>> JB >>>> >>>>> Le 9 févr. 2021 à 11:41, Mohamed-Tayeb BENTERKI <[email protected]> a >>>> écrit : >>>>> >>>>> Hello, >>>>> >>>>> I propose to move the CI from Jenkins to GithubActions, the idea behind >>>> it, >>>>> to centralise all the interaction and PR validation process in one >> place >>>>> and also the stability and speed of execution of the GHA as Jenkins >> does. >>>>> IMHO, I think this will really simplify the development process and >>>>> increase the quality of the releases. >>>>> >>>>> Note: >>>>> - There is no impact on the Unomi code base. >>>>> - If you like the idea and the benefit, I will take care of the >>>>> implementation and its finalisation (at the moment I am adding PR so >> that >>>>> this can be checked and I have also asked the infra team to provide us >>>> with >>>>> credentials for nexus deployment). >>>>> >>>>> Thoughts? >>>>> Regards >>>> >>>> >> >>
