Replace Travis with GitHub Actions

[glensc]

• GHA Jobs not appearing under Checks. Probably needs to be merged to master first.
• Zend_Ldap_ConverterTest::testToLdapSerialize: Fixed by using CI instead of TRAVIS env
• Zend_Db_Table_Select_MysqliTest::testSelectWhereWithTypeFloat
  Zend_Db_Select::_join(): Error occurred while closing statement
• Zend_Locale_FormatTest::testToFloatSetlocale

[glensc]

@falkenhawk can you check if GitHub Actions need to be enabled for this to work?

[falkenhawk]

hi Elan, I don't see any specific option to enable for gha to run here. They are enabled by default. Perhaps there is a setting to toggle on your fork?
Or try with pull_request_target maybe? https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks

Do you think there might be a chance to have GHA running for full range 5.3-8.0 of php versions, as it was on travis?

[glensc]

1) Zend_Ldap_ConverterTest::testToLdapSerialize with data set #2 ('O:8:"DateTime":3:{s:4:"date";s:19:"1970-01-01 00:00:00";s:13:"timezone_type";i:1;s:8:"timezone";s:6:"+00:00";}', DateTime)
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'O:8:"DateTime":3:{s:4:"date";s:19:"1970-01-01 00:00:00";s:13:"timezone_type";i:1;s:8:"timezone";s:6:"+00:00";}'
+'O:8:"DateTime":3:{s:4:"date";s:26:"1970-01-01 00:00:00.000000";s:13:"timezone_type";i:1;s:8:"timezone";s:6:"+00:00";}'

• 5.5: https://github.com/glensc/php-zf1s/runs/1491536496?check_suite_focus=true
• 5.4: https://github.com/glensc/php-zf1s/runs/1491536480?check_suite_focus=true

the other versions pass (note this is without mysql and pgsql yet):

• https://github.com/glensc/php-zf1s/runs/1491593402?check_suite_focus=true

I wonder, is it related to some php.ini setting?

[glensc]

@falkenhawk do you have a list of PHP extensions needed for the test suite? from Travis config I see memcache, memcached, and ldap are added, but no info about other already present extensions.

[glensc]

Zend_Ldap_ConverterTest::testToLdapSerialize uses serialize :

• https://github.com/zf1s/zf1/blob/1.13.4/packages/zend-ldap/library/Zend/Ldap/Converter.php#L213

[glensc]

Seems Zend_Ldap_ConverterTest::testToLdapSerialize was already broken, just earlier skipped with TRAVIS env, need to change those to CI env check.

• https://github.com/zf1s/zf1/blob/1.13.4/tests/Zend/Ldap/ConverterTest.php#L124

eventually, remove the Travis specific exceptions, perhaps the input data could be all set same for all versions. but I'm leaving out that for now out of this PR.

[glensc]

any ideas on this one?

1) Zend_Db_Table_Select_MysqliTest::testSelectWhereWithTypeFloat
Zend_Db_Select::_join(): Error occurred while closing statement

/home/runner/work/php-zf1s/php-zf1s/packages/zend-db/library/Zend/Db/Select.php:852
/home/runner/work/php-zf1s/php-zf1s/packages/zend-db/library/Zend/Db/Select.php:251
/home/runner/work/php-zf1s/php-zf1s/tests/Zend/Db/Select/TestCommon.php:859
/home/runner/work/php-zf1s/php-zf1s/tests/Zend/Db/Select/TestCommon.php:876

happens with 5.5 and 5.4 only:

• https://github.com/glensc/php-zf1s/runs/1491945187?check_suite_focus=true

[glensc]

1. Zend_Db_Table_Select_MysqliTest::testSelectWhereWithTypeFloat
   Zend_Db_Select::_join(): Error occurred while closing statement

this makes no sense:

• zf1/packages/zend-db/library/Zend/Db/Select.php

  Line 852 in 8e1040b

  $this->_parts[self::FROM][$correlationName] = array(

how can array value assignment produce such error? all the values are variables, no function calls:

            $this->_parts[self::FROM][$correlationName] = array(
                'joinType'      => $type,
                'schema'        => $schema,
                'tableName'     => $tableName,
                'joinCondition' => $cond
                );

I can not find any match for such error message in zf1s codebase...

[glensc]

Seems the error comes from ext/mysqli:

• https://github.com/php/php-src/blob/php-5.4.45/ext/mysqli/mysqli.c#L165

@falkenhawk what can we do here with that?

[glensc]

1) Zend_Locale_FormatTest::testToFloatSetlocale
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'1 234,50'
+'123 4,5,00'

/home/runner/work/php-zf1s/php-zf1s/tests/Zend/Locale/FormatTest.php:947

locale test goes totally bizarre after installing required locales. note two commas in value!

the input number is $myFloat = 1234.5;

it fails in all PHP versions except 7.4!

• https://github.com/glensc/php-zf1s/runs/1509613347?check_suite_focus=true
• https://github.com/zf1s/zf1/blob/1.13.4/tests/Zend/Locale/FormatTest.php#L947

[glensc]

seems enabling locale tests by installing needed locales, brings more trouble than needed.

the tests are not run in proper isolation, i.e global resource like locale must be restored after a test, and that is not performed, neither are tests run in isolation (i think phpunit 3.7 does not even support that), and sql queries are written with very bad style, resulting syntax error as numeric value value formatted with comma according to locale rules, gets parsed as two values in sql.

2) Zend_Db_Table_Select_MysqliTest::testSelectWhereOr
Zend_Db_Exception: SQL error for "INSERT INTO `zfprice` (`product_id`, `price_name`, `price_total`) VALUES (1, 'Price 1', 200,45)": Column count doesn't match value count at row 1

• https://github.com/glensc/php-zf1s/runs/1510708630?check_suite_focus=true

[falkenhawk]

Whoa that's some struggle here. You are doing a tremendous job @glensc thank you!

I am sorry I cannot be of much help here as I am currently busy with other work-related stuff...
Perhaps keep Travis enabled in parallel until you're satisfied with the GHA result? yes let's still have travis running (as long as it works, but who knows for how long - I can sense some bad vibes since they were aquired by another company - it looks like they are on a downward spiral only to be shut down at some point soon - note that's only my guess) - until the point we are satisfied with the GHA result, but please continue on this PR as long as you have resources for it and feel that motivation 🙈

How come Travis had not been throwing such errors before 🤔 (locale, db, etc.)

[glensc]

My guess why Travis did not fail on these, as those tests were skipped.

The ext/mysqli failure, is my guess that 5.4 and 5.5 have some bug, which did not manifest on Travis built PHP (different OS, different compiler) but could be that maybe ext/mysqli tests were not ran in Travis.

I've also felt Travis downfall, in projects I was forced to switch to GHA because Travis's pipeline was in the queue for days, which is not acceptable. And at some point the Travis integration was not visible in GitHub at all, had to contact Travis support, and they said I need to remove the token and setup Integration again.

[falkenhawk]

Current status - travis: (php 8.0)

OK, but incomplete or skipped tests!

Tests: 15522, Assertions: 61406, Incomplete: 22, Skipped: 607.

GHA: (php 8.0)

OK, but incomplete or skipped tests!
Tests: 15572, Assertions: 61706, Incomplete: 21, Skipped: 586.

There are even less tests skipped on GHA compared to travis. 🎉
Thank you @glensc for your excellent work here. It would not be possible without your contributions!

So I think the migration can be considered as complete now and travis config can be deleted?

[glensc]

@falkenhawk thanks for your kind words. yes, Travis can be deleted.

not sure about this PR in particular, here may be some changes that haven't been extracted to separate PR. This PR itself is not mergeable, and rebase is not worthy of it. but could do another merge commit here and see what changes remained.

[glensc]

From the top of my head I recall problematic were MySQL, locale tests. Actually locale tests are GHA only, they were not properly done in Travis.

I think memcache and pgsql may be still missing from GitHub Actions.

[glensc]

Merged changes from origin/master. Some changes remaining, if you wish you could cherry-pick them. But seems mostly those are just because the changes extracted here were solved differently after review. And some spelling fixes and missing properties are not that important.