[GH-ISSUE #1488] How about using Github Actions instead of Travis CI? #782

New issue

Closed

opened 2026-03-04 01:48:45 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:48:45 +03:00

Owner

Originally created by @ggtakec on GitHub (Dec 2, 2020).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1488

I would like to be able to test various operating systems at the same time in the s3fs-fuse test.
Then I was trying to add some OS to my current Travis CI tests.
But I found some problem described below.

About Travis CI issues

TravisCI is closing travis-ci.org and moving to travis-ci.com.
(Already, we have moved to travis-ci.com.)
At travis-ci.com, not everything is free and it provides free plan for public repositories.
This free plan allows user to build 1000min/month.
(For public organization, this limit may be higher or even higher. But I have not investigated in detail.)

However, if you run a CI test on multiple OSs, it will take about 20min to build each OS, so it will consume several times that amount(count of OSs).
If you test 5 OSs, it takes 100min for all.
Then If you build 10 times a month, you will exceed this free plan.

And if you exceed that, you will not be able to build individually unless you change to a paid plan instead of a free plan.
(The amount is a minimum of $69 and +$15 if you need macos)
The worst thing for me is that with the free plan I was able to build in 10 concurrent, but I'm limited to running in 1concurrent(or 2).
(In the case of the minimum paid plan, it will be 1 concurrent, and in the case of 5 OS, it will wait 100 minutes.)

Collaborators on s3fs-fuse will consume this build time on travis-ci.com just by forking and building s3fs-fuse.(If they have travis-ci.com settings)
This will happen if collaborators build/test the code in their repository before post the PR.

Perhaps the charge for CI is similar for other CIs such as CircleCI.(I have not confirmed it, but it seems to be the same as far as I can see the documents etc.)

How about solving it with Github Actions?

I think that s3fs-fuse should pass the CI test of the supported all OSs.
At this time, I think that the above problems(charging for CI) may affect committers and collaborators in no small measure.

Therefore, we are considering running CI(test) on Github Actions.
Currently, I'm trying with 11OS(version), and it can all be done in parallel and seems to be running for free.

PR for switch to Github Actions

I will soon make PR that uses Github Actions. It has an expanded OS to be tested.(macos10 etc.)
If that PR is merged, I also want to see if I want to stop testing on Travis CI.

Originally created by @ggtakec on GitHub (Dec 2, 2020). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1488 I would like to be able to test various operating systems at the same time in the s3fs-fuse test. Then I was trying to add some OS to my current Travis CI tests. But I found some problem described below. ### About Travis CI issues TravisCI is closing travis-ci.org and moving to travis-ci.com. (Already, we have moved to travis-ci.com.) At travis-ci.com, not everything is free and it provides `free plan` for public repositories. This `free plan` allows user to build 1000min/month. (For public organization, this limit may be higher or even higher. But I have not investigated in detail.) However, if you run a CI test on multiple OSs, it will take about 20min to build each OS, so it will consume several times that amount(count of OSs). If you test 5 OSs, it takes 100min for all. Then If you build 10 times a month, you will exceed this free plan. And if you exceed that, you will not be able to build individually unless you change to a paid plan instead of a free plan. (The amount is a minimum of $69 and +$15 if you need macos) The worst thing for me is that with the free plan I was able to build in 10 concurrent, but I'm limited to running in 1concurrent(or 2). (In the case of the minimum paid plan, it will be 1 concurrent, and in the case of 5 OS, it will wait 100 minutes.) Collaborators on s3fs-fuse will consume this build time on travis-ci.com just by forking and building s3fs-fuse.(If they have travis-ci.com settings) This will happen if collaborators build/test the code in their repository before post the PR. Perhaps the charge for CI is similar for other CIs such as CircleCI.(I have not confirmed it, but it seems to be the same as far as I can see the documents etc.) ### How about solving it with Github Actions? I think that s3fs-fuse should pass the CI test of the supported all OSs. At this time, I think that the above problems(charging for CI) may affect committers and collaborators in no small measure. Therefore, we are considering running CI(test) on Github Actions. Currently, I'm trying with 11OS(version), and it can all be done in parallel and seems to be running for free. ### PR for switch to Github Actions I will soon make PR that uses Github Actions. It has an expanded OS to be tested.(macos10 etc.) If that PR is merged, I also want to see if I want to stop testing on Travis CI.

kerem closed this issue

2026-03-04 01:48:46 +03:00

kerem commented

2026-03-04 01:48:46 +03:00

Author

Owner

@gaul commented on GitHub (Dec 4, 2020):

I think using a different CI is fine as long as FUSE and macOS work. While Travis was very good 5 years ago when we started using it perhaps other options are better today.

@gaul commented on GitHub (Dec 4, 2020): I think using a different CI is fine as long as FUSE and macOS work. While Travis was very good 5 years ago when we started using it perhaps other options are better today.

kerem commented

2026-03-04 01:48:46 +03:00

Author

Owner

@ggtakec commented on GitHub (Dec 5, 2020):

Yes, that's right.
I also knew Travis CI to be a very good CI, and it had helped us a lot.
But now I think that the number that can be executed in parallel is the biggest obstacle.

If #1489 is merged and there is no problem, I will unset TravisCI after the merge.

@ggtakec commented on GitHub (Dec 5, 2020): Yes, that's right. I also knew Travis CI to be a very good CI, and it had helped us a lot. But now I think that the number that can be executed in parallel is the biggest obstacle. If #1489 is merged and there is no problem, I will unset TravisCI after the merge.

kerem commented

2026-03-04 01:48:46 +03:00

Author

Owner

@ggtakec commented on GitHub (Dec 8, 2020):

When I post #1489, the macos10 test was successful, but after merging Github Actions failed by macos10.
Subsequent Scheduled tests also failed with macos10 and debian:buster.(debian:buster seems to be transient.)
The failure on macos10 is of unknown cause and is currently under investigation.

@ggtakec commented on GitHub (Dec 8, 2020): When I post #1489, the macos10 test was successful, but after merging Github Actions failed by macos10. Subsequent `Scheduled` tests also failed with macos10 and debian:buster.(debian:buster seems to be transient.) The failure on macos10 is of unknown cause and is currently under investigation.

kerem commented

2026-03-04 01:48:46 +03:00

Author

Owner

@ggtakec commented on GitHub (Jan 4, 2021):

I have unset Travis CI and set the build of Gtihub Actions as required.

If we want to re-install Travis CI in the future, please refer to .travis.yml which was deleted in PR of #1512.

@ggtakec commented on GitHub (Jan 4, 2021): I have unset Travis CI and set the build of Gtihub Actions as `required`. If we want to re-install Travis CI in the future, please refer to .travis.yml which was deleted in PR of #1512.