You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Hector Espert <he...@gmail.com> on 2020/05/24 12:05:10 UTC
TravisCI vs Jenkins vs GitHub Actions
Hi everybody.
I would like to open a discussion about with continuous integration service
we should use.
I like Travis CI, but after deal with it in the Netbeans project, I start
to think that they aren't a good couple.
There are two Travis CI limits that are a pain in the neck, the log length
limit and the job limit to 50 min. I found that is a common problem and
other Apache projects are migrating his pipelines from Travis or are
thinking about that.
https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines
https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
I would like to suggest two options.
First , the most conservative option, migrate TravisCI pipeline to the
Apache Jenkins infrastructure.
The problem that i see with this option is if we can integrate the Apache
Jenkins infrastructure with GitHub to run the test suite for every
PR/commits and show the results in the GitHub ui.
The other option, is start to test with the GitHub workflows and if they
are better than TravisCI move to use GitHub workflows instead TravisCI.
Re: TravisCI vs Jenkins vs GitHub Actions
Posted by Mario Schroeder <ma...@gmail.com>.
A while ago, I migrated the CI service for my NetBeans plugin from Travis
CI to GitHub Actions. The setup for the new pipeline was quite easy.
I decided for it because:
- It felt natural to have everything in one place.
- No need to give permissions to an app outside.
- You can have several workflows which are separated by file.
- IMHO GitHub's UI looks neater.
Am So., 24. Mai 2020 um 14:05 Uhr schrieb Hector Espert <
hectorespertpardo@gmail.com>:
> Hi everybody.
>
> I would like to open a discussion about with continuous integration service
> we should use.
>
>
> I like Travis CI, but after deal with it in the Netbeans project, I start
> to think that they aren't a good couple.
>
> There are two Travis CI limits that are a pain in the neck, the log length
> limit and the job limit to 50 min. I found that is a common problem and
> other Apache projects are migrating his pipelines from Travis or are
> thinking about that.
>
>
> https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines
>
>
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>
>
> I would like to suggest two options.
>
> First , the most conservative option, migrate TravisCI pipeline to the
> Apache Jenkins infrastructure.
>
> The problem that i see with this option is if we can integrate the Apache
> Jenkins infrastructure with GitHub to run the test suite for every
> PR/commits and show the results in the GitHub ui.
>
> The other option, is start to test with the GitHub workflows and if they
> are better than TravisCI move to use GitHub workflows instead TravisCI.
>
Re: TravisCI vs Jenkins vs GitHub Actions
Posted by Hector Espert <he...@gmail.com>.
Hi everybody
I'm experimenting to move some jobs from Travis to a Jenkins pipeline
running in the Apache infra.
The PR with the changes is here:
https://github.com/apache/netbeans/pull/2443 and this is the Jenkins job:
https://ci-builds.apache.org/job/Netbeans/job/netbeans-github/
The CloudBees SCM Reporting plugin that is available after the CloudBees
migration allows us to display junit reports in the GitHub interface or
directly in the Jenkins details.
To do the same thing with Travis or with the GitHub actions, we would need
to use an external app.
Moreover, it can substitute this Jenkins jobs:
https://ci-builds.apache.org/job/Netbeans/job/netbeans-license/ and
https://ci-builds.apache.org/job/Netbeans/job/netbeans-linux/
Would it be nice to activate these to run in Jenkins or maintain these in
Travis?
El mié., 10 jun. 2020 a las 22:20, Hector Espert (<
hectorespertpardo@gmail.com>) escribió:
> Hi, I created another PR to move the MacOS job from Travis to the GitHub
> action: https://github.com/apache/netbeans/pull/2180
> The current GitHub action environment for macOS builds has the JDK 1.8
> installed by default in comparison with Travis CI that needs a work around
> to install an older java version.
>
>
> El mar., 26 may. 2020 a las 22:22, Hector Espert (<
> hectorespertpardo@gmail.com>) escribió:
>
>> Hi,
>>
>> I created a draft PR to start testing GitHub actions:
>> https://github.com/apache/netbeans/pull/2158
>>
>> It runs build and test platform/core.network module in a Windows machine.
>>
>> After 12.0 release I would like merge it in the main repo and check how
>> it's working with new PR and commits.
>>
>> El dom., 24 may. 2020 a las 16:59, Jan Lahoda (<la...@gmail.com>)
>> escribió:
>>
>>> Hi,
>>>
>>> I don't mind using a different service, but let me point out the build
>>> currently consumes quite some resources (and is likely to consume more in
>>> the future[1]). I believe ASF is contributing to Travis, so that there
>>> are
>>> more concurrent builds available on Travis for us[2]. We should check
>>> that
>>> whatever other service we use, we can still test in reasonable time.
>>> Also,
>>> I would not want to test less - we should rather test more, to improve
>>> stability.
>>>
>>> [1] https://github.com/apache/netbeans/pull/2121
>>> [2]
>>> https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
>>>
>>> Jan
>>>
>>> On Sun, May 24, 2020 at 2:05 PM Hector Espert <
>>> hectorespertpardo@gmail.com>
>>> wrote:
>>>
>>> > Hi everybody.
>>> >
>>> > I would like to open a discussion about with continuous integration
>>> service
>>> > we should use.
>>> >
>>> >
>>> > I like Travis CI, but after deal with it in the Netbeans project, I
>>> start
>>> > to think that they aren't a good couple.
>>> >
>>> > There are two Travis CI limits that are a pain in the neck, the log
>>> length
>>> > limit and the job limit to 50 min. I found that is a common problem and
>>> > other Apache projects are migrating his pipelines from Travis or are
>>> > thinking about that.
>>> >
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines
>>> >
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>>> >
>>> >
>>> > I would like to suggest two options.
>>> >
>>> > First , the most conservative option, migrate TravisCI pipeline to the
>>> > Apache Jenkins infrastructure.
>>> >
>>> > The problem that i see with this option is if we can integrate the
>>> Apache
>>> > Jenkins infrastructure with GitHub to run the test suite for every
>>> > PR/commits and show the results in the GitHub ui.
>>> >
>>> > The other option, is start to test with the GitHub workflows and if
>>> they
>>> > are better than TravisCI move to use GitHub workflows instead TravisCI.
>>> >
>>>
>>
Re: TravisCI vs Jenkins vs GitHub Actions
Posted by Hector Espert <he...@gmail.com>.
Hi, I created another PR to move the MacOS job from Travis to the GitHub
action: https://github.com/apache/netbeans/pull/2180
The current GitHub action environment for macOS builds has the JDK 1.8
installed by default in comparison with Travis CI that needs a work around
to install an older java version.
El mar., 26 may. 2020 a las 22:22, Hector Espert (<
hectorespertpardo@gmail.com>) escribió:
> Hi,
>
> I created a draft PR to start testing GitHub actions:
> https://github.com/apache/netbeans/pull/2158
>
> It runs build and test platform/core.network module in a Windows machine.
>
> After 12.0 release I would like merge it in the main repo and check how
> it's working with new PR and commits.
>
> El dom., 24 may. 2020 a las 16:59, Jan Lahoda (<la...@gmail.com>)
> escribió:
>
>> Hi,
>>
>> I don't mind using a different service, but let me point out the build
>> currently consumes quite some resources (and is likely to consume more in
>> the future[1]). I believe ASF is contributing to Travis, so that there are
>> more concurrent builds available on Travis for us[2]. We should check that
>> whatever other service we use, we can still test in reasonable time. Also,
>> I would not want to test less - we should rather test more, to improve
>> stability.
>>
>> [1] https://github.com/apache/netbeans/pull/2121
>> [2]
>> https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
>>
>> Jan
>>
>> On Sun, May 24, 2020 at 2:05 PM Hector Espert <
>> hectorespertpardo@gmail.com>
>> wrote:
>>
>> > Hi everybody.
>> >
>> > I would like to open a discussion about with continuous integration
>> service
>> > we should use.
>> >
>> >
>> > I like Travis CI, but after deal with it in the Netbeans project, I
>> start
>> > to think that they aren't a good couple.
>> >
>> > There are two Travis CI limits that are a pain in the neck, the log
>> length
>> > limit and the job limit to 50 min. I found that is a common problem and
>> > other Apache projects are migrating his pipelines from Travis or are
>> > thinking about that.
>> >
>> >
>> >
>> https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines
>> >
>> >
>> >
>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>> >
>> >
>> > I would like to suggest two options.
>> >
>> > First , the most conservative option, migrate TravisCI pipeline to the
>> > Apache Jenkins infrastructure.
>> >
>> > The problem that i see with this option is if we can integrate the
>> Apache
>> > Jenkins infrastructure with GitHub to run the test suite for every
>> > PR/commits and show the results in the GitHub ui.
>> >
>> > The other option, is start to test with the GitHub workflows and if they
>> > are better than TravisCI move to use GitHub workflows instead TravisCI.
>> >
>>
>
Re: TravisCI vs Jenkins vs GitHub Actions
Posted by Hector Espert <he...@gmail.com>.
Hi,
I created a draft PR to start testing GitHub actions:
https://github.com/apache/netbeans/pull/2158
It runs build and test platform/core.network module in a Windows machine.
After 12.0 release I would like merge it in the main repo and check how
it's working with new PR and commits.
El dom., 24 may. 2020 a las 16:59, Jan Lahoda (<la...@gmail.com>) escribió:
> Hi,
>
> I don't mind using a different service, but let me point out the build
> currently consumes quite some resources (and is likely to consume more in
> the future[1]). I believe ASF is contributing to Travis, so that there are
> more concurrent builds available on Travis for us[2]. We should check that
> whatever other service we use, we can still test in reasonable time. Also,
> I would not want to test less - we should rather test more, to improve
> stability.
>
> [1] https://github.com/apache/netbeans/pull/2121
> [2] https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
>
> Jan
>
> On Sun, May 24, 2020 at 2:05 PM Hector Espert <hectorespertpardo@gmail.com
> >
> wrote:
>
> > Hi everybody.
> >
> > I would like to open a discussion about with continuous integration
> service
> > we should use.
> >
> >
> > I like Travis CI, but after deal with it in the Netbeans project, I start
> > to think that they aren't a good couple.
> >
> > There are two Travis CI limits that are a pain in the neck, the log
> length
> > limit and the job limit to 50 min. I found that is a common problem and
> > other Apache projects are migrating his pipelines from Travis or are
> > thinking about that.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines
> >
> >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> >
> >
> > I would like to suggest two options.
> >
> > First , the most conservative option, migrate TravisCI pipeline to the
> > Apache Jenkins infrastructure.
> >
> > The problem that i see with this option is if we can integrate the Apache
> > Jenkins infrastructure with GitHub to run the test suite for every
> > PR/commits and show the results in the GitHub ui.
> >
> > The other option, is start to test with the GitHub workflows and if they
> > are better than TravisCI move to use GitHub workflows instead TravisCI.
> >
>
Re: TravisCI vs Jenkins vs GitHub Actions
Posted by Jan Lahoda <la...@gmail.com>.
Hi,
I don't mind using a different service, but let me point out the build
currently consumes quite some resources (and is likely to consume more in
the future[1]). I believe ASF is contributing to Travis, so that there are
more concurrent builds available on Travis for us[2]. We should check that
whatever other service we use, we can still test in reasonable time. Also,
I would not want to test less - we should rather test more, to improve
stability.
[1] https://github.com/apache/netbeans/pull/2121
[2] https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
Jan
On Sun, May 24, 2020 at 2:05 PM Hector Espert <he...@gmail.com>
wrote:
> Hi everybody.
>
> I would like to open a discussion about with continuous integration service
> we should use.
>
>
> I like Travis CI, but after deal with it in the Netbeans project, I start
> to think that they aren't a good couple.
>
> There are two Travis CI limits that are a pain in the neck, the log length
> limit and the job limit to 50 min. I found that is a common problem and
> other Apache projects are migrating his pipelines from Travis or are
> thinking about that.
>
>
> https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines
>
>
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>
>
> I would like to suggest two options.
>
> First , the most conservative option, migrate TravisCI pipeline to the
> Apache Jenkins infrastructure.
>
> The problem that i see with this option is if we can integrate the Apache
> Jenkins infrastructure with GitHub to run the test suite for every
> PR/commits and show the results in the GitHub ui.
>
> The other option, is start to test with the GitHub workflows and if they
> are better than TravisCI move to use GitHub workflows instead TravisCI.
>