+1 to move to GHA if it works. We already have this on other Apache projects, we build only master and snapshot deployment on Jenkins and PRs on GHA but we can do all on GHA, just need to use github secrets to manage Apache Nexus repository for deployment.
regards, François [email protected] Le 09/02/2021 à 16:40, Serge Huber a écrit : > Hi Taybou, > > Thanks for the proposal. I actually like this idea because I've been having > a recurring problem with Jenkins not working with some Yarn issue and I'm > hoping that maybe another platform such as Github will give us less > trouble. > > Also, the Jenkins server is (for me) quite complex to understand and I find > the github infra easier to understand. > > In the end it doesn't really matter which CI system we use but we do need > to find a way to have reliable and repeatable testing, which is (still) not > the case and is a problem notably to guarantee contributions. > > As you seem motivated to do the work I'm in favor of this change. I also > checked to see that other Apache projects are using it. > > JB, could you elaborate what the problem is with the number of jobs started > on Beam and Airflow? How would this be different with Jenkins? > > cheers, > Serge... > > On Tue, Feb 9, 2021 at 4:28 PM Jean-Baptiste Onofre <[email protected]> wrote: > >> 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 >>>>>> >>>> >>
