Re: [ALL] components still using Travis

[Alex Herbert]

On Fri, 27 May 2022 at 13:04, Matt Juntunen 
wrote:

> +1 as well.
>
> Thanks, Alex! I have spent quite a bit of time refreshing the Travis
> build page over and over waiting for my builds to start, so this will
> be a welcome change :-)
>

I have added workflows to:

- Numbers
- Statistics
- Geometry

using a similar configuration to RNG.

All can build the main modules in JDK 8, 11, 17 with the default maven
goal. The examples modules have extra requirements. Note here that the
previous travis setup would only build the parent module for the examples,
i.e. no recursion into the actual modules. Thus the previous CI was not
actually building the examples. With the GH action the target directory can
be set to the examples directory and then maven will recursively build all
child example modules.

Geometry required a more lenient goal to build the examples. Spotbugs
failed locally with JDK 17 for the JMH module. Feel free to have a look and
see what you think.

Note that building the examples modules, especially JMH, in numbers,
statistics and rng also requires some tweaks. PMD is typically set to not
fail the build (or simply to disabled for JMH to ignore all the generated
files).

RNG and Numbers cannot build the examples with JDK 8 and so currently only
target JDK 11. Thus it works with the default goal. Under JDK 17 I think it
would fail for the javadoc. I plan to get it to build on JDK 17 in the
future as this often spots issues that JDK 11 javadoc will ignore.

I have not yet tackled Math as its travis config only ever used JDK 8.
There may be a lot of issues with JDK 11 and 17 so I am leaving that for
another day when I have had a chance to test locally.

The codecov configuration for multiple modules requires a single line list
of files. For unknown reasons a valid multi-line YAML entry in quotes does
not concatenate and strip whitespace as expected. I initially missed this
as it is not reported as invalid YAML. But the coverage reports only had
the first module present.

IIRC once the coverage has made a few submissions then codecov starts
building nice reports. URLs should be:

https://app.codecov.io/gh/apache/commons-geometry
https://app.codecov.io/gh/apache/commons-numbers
https://app.codecov.io/gh/apache/commons-statistics
https://app.codecov.io/gh/apache/commons-rng

Final note is that the GH actions typically take a few minutes to complete
after a push. Thus I could test setup very quickly and correct errors. When
all is running smoothly we can disable travis and update the build and
coverage badges in the README.md files.

Alex

Re: [ALL] components still using Travis

[Matt Juntunen]

+1 as well.

Thanks, Alex! I have spent quite a bit of time refreshing the Travis
build page over and over waiting for my builds to start, so this will
be a welcome change :-)

-Matt J

On Thu, May 26, 2022 at 3:55 PM Bruno Kinoshita  wrote:
>
> +1
>
> Thanks Alex!
>
> On Fri, 27 May 2022, 3:13 am Alex Herbert,  wrote:
>
> > Continuing the thread about switching Travis to GitHub actions...
> >
> > Commons RNG has been running travis and GH actions in parallel now for 6
> > weeks as an experiment.
> >
> > Some PRs have been missed by Travis. The master branch continues to be
> > built for all commits. The latest PR was built but about 12 hours after the
> > push. In comparison GH actions has been very fast, often building within a
> > few minutes.
> >
> > So Travis support is flaky for PRs and slower than GH. I propose to drop
> > travis for RNG and migrate the following multi-module math derived projects
> > to GH actions:
> >
> > - Numbers
> > - Statistics
> > - Math
> > - Geometry
> >
> > One item to note is that to obtain code coverage requires a switch from
> > coveralls to codecov. For RNG this could use a single aggregate jacoco
> > report as the multi-module project has an aggregator module for coverage
> > and javadoc reports. However the codecov documentation indicates that a
> > comma separated list of reports can be used. So as a test I will try and
> > configure this for the 11 modules we have in numbers.
> >
> > This change will require redirection of the CI build status and coverage
> > badges in the README.md page for each module.
> >
> > Alex
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[Bruno Kinoshita]

+1

Thanks Alex!

On Fri, 27 May 2022, 3:13 am Alex Herbert,  wrote:

> Continuing the thread about switching Travis to GitHub actions...
>
> Commons RNG has been running travis and GH actions in parallel now for 6
> weeks as an experiment.
>
> Some PRs have been missed by Travis. The master branch continues to be
> built for all commits. The latest PR was built but about 12 hours after the
> push. In comparison GH actions has been very fast, often building within a
> few minutes.
>
> So Travis support is flaky for PRs and slower than GH. I propose to drop
> travis for RNG and migrate the following multi-module math derived projects
> to GH actions:
>
> - Numbers
> - Statistics
> - Math
> - Geometry
>
> One item to note is that to obtain code coverage requires a switch from
> coveralls to codecov. For RNG this could use a single aggregate jacoco
> report as the multi-module project has an aggregator module for coverage
> and javadoc reports. However the codecov documentation indicates that a
> comma separated list of reports can be used. So as a test I will try and
> configure this for the 11 modules we have in numbers.
>
> This change will require redirection of the CI build status and coverage
> badges in the README.md page for each module.
>
> Alex
>

Re: [ALL] components still using Travis

[Alex Herbert]

Continuing the thread about switching Travis to GitHub actions...

Commons RNG has been running travis and GH actions in parallel now for 6
weeks as an experiment.

Some PRs have been missed by Travis. The master branch continues to be
built for all commits. The latest PR was built but about 12 hours after the
push. In comparison GH actions has been very fast, often building within a
few minutes.

So Travis support is flaky for PRs and slower than GH. I propose to drop
travis for RNG and migrate the following multi-module math derived projects
to GH actions:

- Numbers
- Statistics
- Math
- Geometry

One item to note is that to obtain code coverage requires a switch from
coveralls to codecov. For RNG this could use a single aggregate jacoco
report as the multi-module project has an aggregator module for coverage
and javadoc reports. However the codecov documentation indicates that a
comma separated list of reports can be used. So as a test I will try and
configure this for the 11 modules we have in numbers.

This change will require redirection of the CI build status and coverage
badges in the README.md page for each module.

Alex

Re: [ALL] components still using Travis

[sebb]

On Wed, 30 Mar 2022 at 12:42, Eric Bresie  wrote:
>
> Not sure if this is applicable here but is there a concern about limits of 
> amount of usage on GItHub activities (and/or Travis) for a given organization 
> across all of the Apache / Common projects/repositories?

You would need to raise this with Infra: us...@infra.apache.org

> Eric Bresie
> ebre...@gmail.com (mailto:ebre...@gmail.com)
>
> > On March 29, 2022 at 6:21:53 AM CDT, sebb  > (mailto:seb...@gmail.com)> wrote:
> > It looks like there is a general move to switch from Travis to GitHub 
> > Actions.
> > AFAICT the following components are still using Travis:
> >
> > geometry
> > jelly
> > jxpath
> > math
> > numbers
> > rng
> > weaver
> >
> > Do we need to move these as well?
> >
> > BTW, emails from GHA runs can now be directed to project mailing
> > lists, which is great (*)
> > See: https://s.apache.org/asfyaml-gha
> >
> > e.g. update .asf.yaml to include:
> > notifications:
> > ...
> > jobs: notificati...@commons.apache.org 
> > (mailto:notificati...@commons.apache.org)
> >
> > Sebb.
> > (*) Travis always had this, but recently switched to a new email
> > system which means all such mails have to be moderated.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> > (mailto:dev-unsubscr...@commons.apache.org)
> > For additional commands, e-mail: dev-h...@commons.apache.org 
> > (mailto:dev-h...@commons.apache.org)
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[Eric Bresie]

Not sure if this is applicable here but is there a concern about limits of 
amount of usage on GItHub activities (and/or Travis) for a given organization 
across all of the Apache / Common projects/repositories?

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On March 29, 2022 at 6:21:53 AM CDT, sebb  (mailto:seb...@gmail.com)> wrote:
> It looks like there is a general move to switch from Travis to GitHub Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
> jobs: notificati...@commons.apache.org 
> (mailto:notificati...@commons.apache.org)
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> (mailto:dev-unsubscr...@commons.apache.org)
> For additional commands, e-mail: dev-h...@commons.apache.org 
> (mailto:dev-h...@commons.apache.org)
>

Re: [ALL] components still using Travis

[Rob Tompkins]

> On Mar 29, 2022, at 10:51 AM, sebb  wrote:
> 
> On Tue, 29 Mar 2022 at 15:27, Rob Tompkins  > wrote:
>> 
>> I wonder if the python script will be effective in doing the migration 
>> properly. I’ll try to carve some time out to help here.
> 
> In the case of Commons, most of the components have very similar
> needs, so one can probably just copy existing workflows from another
> component and adjust slightly.

With youi there….just thinking that it might not be exactly 1-to-1 such that a 
python script automating the migration would work.

-Rob

> 
>> -Rob
>> 
>>> On Mar 29, 2022, at 10:19 AM, sebb  wrote:
>>> 
>>> On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  
>>> wrote:
 
 Hi Sebb,
 
 Yep, geometry is still using Travis. I've never used GitHub Actions so
 I'm not sure what it's capable of. Are there any specific features it
 provides that are driving the migration to it? Or is it more a matter
 of community preference? Either way is fine, I'm just curious.
>>> 
>>> It looks like Infra may be intending to migrate projects:
>>> https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration
>>> 
 Regards,
 Matt J
 
 On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
> 
> It looks like there is a general move to switch from Travis to GitHub 
> Actions.
> AFAICT the following components are still using Travis:
> 
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
> 
> Do we need to move these as well?
> 
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
> 
> e.g. update .asf.yaml to include:
> notifications:
> ...
> jobs: notificati...@commons.apache.org
> 
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
> 

Re: [ALL] components still using Travis

[sebb]

On Tue, 29 Mar 2022 at 15:27, Rob Tompkins  wrote:
>
> I wonder if the python script will be effective in doing the migration 
> properly. I’ll try to carve some time out to help here.

In the case of Commons, most of the components have very similar
needs, so one can probably just copy existing workflows from another
component and adjust slightly.

> -Rob
>
> > On Mar 29, 2022, at 10:19 AM, sebb  wrote:
> >
> > On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  
> > wrote:
> >>
> >> Hi Sebb,
> >>
> >> Yep, geometry is still using Travis. I've never used GitHub Actions so
> >> I'm not sure what it's capable of. Are there any specific features it
> >> provides that are driving the migration to it? Or is it more a matter
> >> of community preference? Either way is fine, I'm just curious.
> >
> > It looks like Infra may be intending to migrate projects:
> > https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration
> >
> >> Regards,
> >> Matt J
> >>
> >> On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
> >>>
> >>> It looks like there is a general move to switch from Travis to GitHub 
> >>> Actions.
> >>> AFAICT the following components are still using Travis:
> >>>
> >>> geometry
> >>> jelly
> >>> jxpath
> >>> math
> >>> numbers
> >>> rng
> >>> weaver
> >>>
> >>> Do we need to move these as well?
> >>>
> >>> BTW, emails from GHA runs can now be directed to project mailing
> >>> lists, which is great (*)
> >>> See: https://s.apache.org/asfyaml-gha
> >>>
> >>> e.g. update .asf.yaml to include:
> >>> notifications:
> >>> ...
> >>>  jobs: notificati...@commons.apache.org
> >>>
> >>> Sebb.
> >>> (*) Travis always had this, but recently switched to a new email
> >>> system which means all such mails have to be moderated.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[Rob Tompkins]

I wonder if the python script will be effective in doing the migration 
properly. I’ll try to carve some time out to help here.

-Rob 

> On Mar 29, 2022, at 10:19 AM, sebb  wrote:
> 
> On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  wrote:
>> 
>> Hi Sebb,
>> 
>> Yep, geometry is still using Travis. I've never used GitHub Actions so
>> I'm not sure what it's capable of. Are there any specific features it
>> provides that are driving the migration to it? Or is it more a matter
>> of community preference? Either way is fine, I'm just curious.
> 
> It looks like Infra may be intending to migrate projects:
> https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration
> 
>> Regards,
>> Matt J
>> 
>> On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
>>> 
>>> It looks like there is a general move to switch from Travis to GitHub 
>>> Actions.
>>> AFAICT the following components are still using Travis:
>>> 
>>> geometry
>>> jelly
>>> jxpath
>>> math
>>> numbers
>>> rng
>>> weaver
>>> 
>>> Do we need to move these as well?
>>> 
>>> BTW, emails from GHA runs can now be directed to project mailing
>>> lists, which is great (*)
>>> See: https://s.apache.org/asfyaml-gha
>>> 
>>> e.g. update .asf.yaml to include:
>>> notifications:
>>> ...
>>>  jobs: notificati...@commons.apache.org
>>> 
>>> Sebb.
>>> (*) Travis always had this, but recently switched to a new email
>>> system which means all such mails have to be moderated.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[sebb]

On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  wrote:
>
> Hi Sebb,
>
> Yep, geometry is still using Travis. I've never used GitHub Actions so
> I'm not sure what it's capable of. Are there any specific features it
> provides that are driving the migration to it? Or is it more a matter
> of community preference? Either way is fine, I'm just curious.

It looks like Infra may be intending to migrate projects:
https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration

> Regards,
> Matt J
>
> On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
> >
> > It looks like there is a general move to switch from Travis to GitHub 
> > Actions.
> > AFAICT the following components are still using Travis:
> >
> > geometry
> > jelly
> > jxpath
> > math
> > numbers
> > rng
> > weaver
> >
> > Do we need to move these as well?
> >
> > BTW, emails from GHA runs can now be directed to project mailing
> > lists, which is great (*)
> > See: https://s.apache.org/asfyaml-gha
> >
> > e.g. update .asf.yaml to include:
> > notifications:
> > ...
> >   jobs: notificati...@commons.apache.org
> >
> > Sebb.
> > (*) Travis always had this, but recently switched to a new email
> > system which means all such mails have to be moderated.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[Alex Herbert]

On Tue, 29 Mar 2022 at 14:43, Gilles Sadowski  wrote:

> Hello.
>
> Le mar. 29 mars 2022 à 15:23, Alex Herbert  a
> écrit :
> >
> > [...]
> >
> > The feature I liked from Travis was the integration of coverage reports
> > from coveralls. This would red light a PR in the main page if coverage
> had
> > dropped. There is no coveralls GHA. I installed the Codecov action for
> > [Collections] as a test a few months ago and it has been sending coverage
> > emails to our dev list since. You can click through and scroll the
> report.
> > I do not think it red lights a PR for low coverage so you have to read
> the
> > report. I am undecided if I prefer the report. No-one else seems to have
> > commented either way. But I think it important that any PR has automated
> > checks that the new code is executed.
>
> IMO, it would be a regression if the move to GH has removed that feature.
>

+1. But flaky integration is a bigger issue. Without a CI build you cannot
get the coverage failure report at all.

There is a way to restart PR builds on Travis CI (e.g. if they fail
spuriously due to randomness as occurs in [RNG]). But there is no way to
force a link up other than waiting a few hours/days and pushing to the PR
branch.

Looking at Travis CI.com, it was running builds for the Geometry PR for
issue 142. The last PR build was 11 days ago, and then a build on master 3
days ago when it was merged. But RNG last had a PR 6 months ago; Numbers
had one 5 months ago. Travis has been building master for all
recent commits.

[1] https://app.travis-ci.com/github/apache/commons-geometry/pull_requests
[2] https://app.travis-ci.com/github/apache/commons-rng/pull_requests
[3] https://app.travis-ci.com/github/apache/commons-numbers/pull_requests

Re: [ALL] components still using Travis

[Gilles Sadowski]

Hello.

Le mar. 29 mars 2022 à 15:23, Alex Herbert  a écrit :
>
> [...]
>
> The feature I liked from Travis was the integration of coverage reports
> from coveralls. This would red light a PR in the main page if coverage had
> dropped. There is no coveralls GHA. I installed the Codecov action for
> [Collections] as a test a few months ago and it has been sending coverage
> emails to our dev list since. You can click through and scroll the report.
> I do not think it red lights a PR for low coverage so you have to read the
> report. I am undecided if I prefer the report. No-one else seems to have
> commented either way. But I think it important that any PR has automated
> checks that the new code is executed.

IMO, it would be a regression if the move to GH has removed that feature.

Gilles

>
> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[Alex Herbert]

On Tue, 29 Mar 2022 at 12:22, sebb  wrote:

> It looks like there is a general move to switch from Travis to GitHub
> Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>

In terms of supporting a CI build on all PRs for a range of platforms then
the two provide the same functionality. I am not opposed to moving to GHA.
It just did not seem necessary.

One issue I have with GH actions is that when a build fails there is no
option to scroll the build output log to the end to see the error. This is
useful for maven's verbose output logs, especially with the multi-module
projects (geometry, math, numbers, rng, statistics). Looking at a recent GH
build you can search in the output log, but not scroll to the end. Maybe
this is different if the build fails; I only looked at one that passed.

The feature I liked from Travis was the integration of coverage reports
from coveralls. This would red light a PR in the main page if coverage had
dropped. There is no coveralls GHA. I installed the Codecov action for
[Collections] as a test a few months ago and it has been sending coverage
emails to our dev list since. You can click through and scroll the report.
I do not think it red lights a PR for low coverage so you have to read the
report. I am undecided if I prefer the report. No-one else seems to have
commented either way. But I think it important that any PR has automated
checks that the new code is executed.

One thing I have noticed is that Travis is a bit flaky. Sometimes it does
not run for PRs. We had a few spells on some projects where the Travis CI
did not link up then magically started working again with no changes to
settings. It's been a while since I looked at a PR using Travis and the
coveralls reports. So I will open one now and see if the integration is
still there.

Having just opened one it does not log a Travis CI build in the GitHub
page. LGTM analysis is running. Travis-ci.com does not pick up the PR. The
last build was 6 days ago on master. [1]

The settings are all good to build PRs. So this is an example of the flaky
support we get from Travis. If nothing else this is a reason to change to
GHA.

Matt uses PRs a lot on geometry to check builds on multiple platforms.
Perhaps he can feedback on whether the Travis integration is working there.


>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
>
Currently if I commit something that breaks a CI build on Travis (or
Jenkins which we use for snapshot deployment) then I receive an e-mail. I
am more likely to respond to personal e-mails than e-mails to a list. Can
GHA target both types of mail?

Alex

[1] https://app.travis-ci.com/github/apache/commons-rng

Re: [ALL] components still using Travis

[Gilles Sadowski]

Hello.

Le mar. 29 mars 2022 à 13:22, sebb  a écrit :
>
> It looks like there is a general move to switch from Travis to GitHub Actions.

AFAIK, there has never been a clear explanation for that move.

> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver

statistics

>
> Do we need to move these as well?

For consistency, or ease of maintenance, provided it is indeed
the case that everything can be configured from ".asf.yaml" (i.e.
no "login in on GH" required).

Regards,
Gilles

>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
>   jobs: notificati...@commons.apache.org
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

[Matt Juntunen]

Hi Sebb,

Yep, geometry is still using Travis. I've never used GitHub Actions so
I'm not sure what it's capable of. Are there any specific features it
provides that are driving the migration to it? Or is it more a matter
of community preference? Either way is fine, I'm just curious.

Regards,
Matt J

On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
>
> It looks like there is a general move to switch from Travis to GitHub Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
>   jobs: notificati...@commons.apache.org
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org