migration CI

[jhdxr]

travis-ci.org will be shutting down in several weeks, are we going to move to travis-ci.com as suggested on its website, or maybe other CI services, e.g. Github Actions?

[morozov]

Github Actions would make more sense IMO. All other open-source projects I'm involved in moved there.

[jhdxr]

Github Actions would make more sense IMO. All other open-source projects I'm involved in moved there.

Same here actually. The reason I proposed travis.com is it won't require us to update/rewrite the configuration file. I have to admit it's not a pleasant task to make the CI can work from 5.3 to the latest. Maybe time to ask the same question again, should we bump the min version requirement? Even Composer is dropping old versions.

[morozov]

AFAIK composer still supports PHP 5.3. Although I'm fine with bumping the minimal requirement to say 7.2:

phpbrew/bin/phpbrew

Lines 4 to 8 in ad346ae

	if (PHP_VERSION_ID < 70200 && function_exists('posix_isatty') && posix_isatty(STDOUT)) {
	fwrite(STDOUT, "\033[33mWarning! The usage of PHP older than 7.2.0 as the interpreter is deprecated.\n");
	fwrite(STDOUT, "Please set the system interpreter using \033[0m'phpbrew system <version>'\033[33m.\n");
	fwrite(STDOUT, "See https://github.com/phpbrew/phpbrew/wiki/System-Interpreter for details.\033[0m\n");
	}

Or even 7.3 given that 7.2 is no longer supported.

Using the system interpreter, it should be possible to build the older versions w/o having them used by PHPBrew as runtime. This would also create an opportunity for replacing the unmaintained dependencies like CurlKit with something more standard like Guzzle, etc.

[jhdxr]

AFAIK composer still supports PHP 5.3

Yes you are right. My bad. Composer is going to drop php older than 7.1 as of v2.2. (https://blog.packagist.com/composer-2-0-is-now-available/)

Using the system interpreter, it should be possible to build the older versions w/o having them used by PHPBrew as runtime.

I have a question. For phar, is it possible to show an error message and exit when we use some features/syntax only available in new versions?

I know it's possible for normal application, we can have a bootup file to check the version, and include(not require) the actual business logical later. The interpreter won't compile those file until it reach the include. But as phar is one single file, I'm not sure if it's still the case.

[jhdxr]

For phar, is it possible to show an error message and exit when we use some features/syntax only available in new versions?

I did a simple test and it also works. (tested on php7.2)

Then I'm totally fine to drop support for old php. Just add an error meesage in our entry file to let the user know. Does it sound good?

[morozov]

I have a question. For phar, is it possible to show an error message and exit when we use some features/syntax only available in new versions?

There's also a feature in Box that allows to enforce the requirements specified in composer.json. We can try using it. This way, we can make sure that not only the PHP version matches but all needed extensions like XML, JSON, etc. are available at runtime.

Then I'm totally fine to drop support for old php. Just add an error meesage in our entry file to let the user know. Does it sound good?

Sounds good to me. It would be also nice (now or later) to integrate this check into the upgrade process. I.e. instead of rewriting the binary right after downloading, execute something like /path/to/the/new/phpbrew --version and only move the file if the command succeeded.

[morozov]

@jhdxr see #1218 which implements the new version validation during the upgrade.

[morozov]

@jhdxr I think at this point we can tag a new release which will contain the logic implemented in #1218. After that, we can drop the support for PHP 7.2 and older and migrate to another CI. Once the next release is tagged, the binary of the previous release won't let the upgrade happen if the old PHP is used. Sounds good?

[jhdxr]

@morozov Sounds great. Just one comment: can we also added an option for selfupdate to let user to force choose the version they want. Just like Composer's --1 and --2.

[morozov]

This seems to be more than trivial to implement. Composer has a few release channels between which --1 and --2 can switch. PHPBrew simply relies on the latest release alias provided by GitHub. I don't think I'll have the bandwidth to implement this in foreseeable future. Do you?

[peter279k]

I've migrated some part of works from Travis CI to GitHub actions in the PR #1268.

And now we've following three works to consider migrating from Travis CI to GitHub actions:

• After running the PHPUnit successfully, it will download the coveralls to upload the code coverage report.
  • This migration should be completed by repository owner because I don't have the coveralls credential key.
• Uploading the phpbrew Phar binary to the Amazon S3.
  • This migration should be completed by repository owner because I don't have the current Amazon S3 key.
• After PHPBrew uploading is successful, using the webhook send the notification to the Gitter.
  • This migration should be completed by repository owner because I don't have the current Gitter credentials.

@c9s, could you evaluate above works that need to migrate from Travis CI to GitHub actions? Or I miss some works in the Travis CI setting?

Thanks 😃.

[jhdxr]

* Uploading the phpbrew Phar binary to the Amazon S3.
  
  * This migration should be completed by repository owner because I don't have the current Amazon S3 key.

I think we can just remove/ignore this actually. The self-update command is using github (https://github.com/phpbrew/phpbrew/releases/latest/download/phpbrew.phar) as source.

[c9s]

Sounds good to me, but does Amazon provide free S3 service?

[peter279k]

Sounds good to me, but does Amazon provide free S3 service?

@c9s, here are the AWS Free tier descriptions, I'm not sure it's good enough for us:

AWS Free Tier
As part of the AWS Free Tier, you can get started with Amazon S3 for free. Upon sign-up, new AWS customers receive 5GB of Amazon S3 storage in the S3 Standard storage class; 20,000 GET Requests; 2,000 PUT, COPY, POST, or LIST Requests; and 100 GB of Data Transfer Out each month.

Your usage for the free tier is calculated each month across all AWS Regions except the AWS GovCloud Region and automatically applied to your bill; unused monthly usage will not roll over. Restrictions apply; see offer terms for more details.

[c9s]

hmm maybe not doing this? let’s upload the phar to the github release? it’s not limited. Chun-Sheng, Li ***@***.***>於 2022年12月8日 週四，上午10:50寫道：

…

Sounds good to me, but does Amazon provide free S3 service? Here are the AWS Free tier description <https://aws.amazon.com/s3/pricing/?nc1=h_ls>, I'm not sure it's good enough for us: AWS Free Tier As part of the AWS Free Tier <https://aws.amazon.com/free/>, you can get started with Amazon S3 for free. Upon sign-up, new AWS customers receive 5GB of Amazon S3 storage in the S3 Standard storage class; 20,000 GET Requests; 2,000 PUT, COPY, POST, or LIST Requests; and 100 GB of Data Transfer Out each month. Your usage for the free tier is calculated each month across all AWS Regions except the AWS GovCloud Region and automatically applied to your bill; unused monthly usage will not roll over. Restrictions apply; see offer terms <https://aws.amazon.com/free/> for more details. — Reply to this email directly, view it on GitHub <#1216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMNTXQAV2NL5RAXMY26Z3WMFEFTANCNFSM4VRGS3YA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[peter279k]

I agree with @c9s. Using the GitHub releases I think is great for us to release upcoming Phar file :).