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 > >> > >> > >
