@Luca, the release pipeline is meant to be the one where we build the final
artifacts for a given release (and also do the push). Additionally, we will
keep nightly in Jenkins too to make sure we won't have a release pipeline
broken.
For GH, overall we should stick to PR checks/automation. More
complex/processing hungry pipelines Jenkins should be the way to go.

Jan also suggested that we might use a custom GH runner/actions that can be
shared with Jenkins, so we reduce the chance to get off guard in a setup.

On Thu, Nov 16, 2023 at 10:57 AM Luca Molteni <[email protected]> wrote:

>
>
> > On 10 Nov 2023, at 19:47, ricardo zanini fernandes <
> [email protected]> wrote:
> >
> > As you know, we are currently working on the CI migration from KIE org to
> > Apache. While doing this, I could find some duplication in the Jenkins
> > pipelines and GHA in a few repositories.
> >
> > I propose to focus our flow and automation on GHA while working on
> > non-release pipelines. For example tests, checks, validation, PR
> > automation, and so on. It's way easier to configure everything on GHA
> > directly. Just bear in mind that only verified actions are valid in this
> > context.
> >
> > For Jenkins, we can let the nightly builds verify if we have a healthy
> > ecosystem and the release work itself.
>
> I agree, but how can we draw the line between release and non release
> pipeline? As I never productised anything, to me it’s not that clear.
> I understood we switched from GH action to Jenkins because we had limited
> resources on GH am I mistaken? In that case we should keep GH jobs as small
> as possible.
>
> Luca
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Reply via email to