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

Reply via email to