Fix ts() usage in activityView() popup. #28
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
totten
added a commit
that referenced
this pull request
Mar 4, 2013
Fix ts() usage in activityView() popup.
eileenmcnaughton
referenced
this pull request
in eileenmcnaughton/civicrm-core
Jan 6, 2015
Edzelopez
added a commit
to Edzelopez/civicrm-core
that referenced
this pull request
Apr 6, 2015
CIVI-28 Added support for delete contribution API
seamuslee001
pushed a commit
to seamuslee001/civicrm-core
that referenced
this pull request
May 19, 2016
CRM-17983 Fix error in data type as found by Dave
f2boot
pushed a commit
to f2boot/civicrm-core
that referenced
this pull request
Sep 25, 2016
CRM-13694 - Check if CIVICRM_SETTINGS_PATH already defined
ErichBSchulz
pushed a commit
to ErichBSchulz/civicrm-core
that referenced
this pull request
Jan 3, 2017
Upgrade to Fuzion 4.6.24
mukeshcompucorp
pushed a commit
to mukeshcompucorp/civicrm-core
that referenced
this pull request
Jan 18, 2018
Merged
mfb
pushed a commit
to mfb/civicrm-core
that referenced
this pull request
Dec 15, 2018
CRM-13003, upgraded selenium server to 2.35.0, which fixes issues with F...
totten
added a commit
to totten/civicrm-core
that referenced
this pull request
Sep 6, 2019
…QL 5.5 Overview -------- This disables a particularly flaky test-scenario. Technical Details ----------------- The `SyntaxConformanceTest::testSqlOperators()` has been rather flaky for a while. (I think this goes back either to the creation of the test or the expansion of Dedupe API -- in other words, the test of this scenario has always been flaky.) When the test fails, it looks like this: ``` api_v3_SyntaxConformanceTest::testSqlOperators with data set civicrm#28 ('Dedupe') incorrect count returned from Dedupe getcount Failed asserting that 0 matches expected 2. /home/jenkins/bknix-min/build/build-1/web/sites/all/modules/civicrm/Civi/Test/Api3TestTrait.php:191 /home/jenkins/bknix-min/build/build-1/web/sites/all/modules/civicrm/tests/phpunit/api/v3/SyntaxConformanceTest.php:1131 /home/jenkins/bknix-min/build/build-1/web/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:215 /home/jenkins/bknix-min/civicrm-buildkit/extern/phpunit6/phpunit6.phar:570 ``` I've spent a chunk of time investigating the flakiness and found: 1. The test usually (possibly always?) passes on MySQL 5.7. 2. The test often (but not always) fails on MySQL 5.5. 3. The version of PHP (php70 vs php72) does not make much difference. 4. The test never seems to fail when run by itself. The smallest scenario which seemd to reliably produce the failure was: ``` env SYNTAX_CONFORMANCE_ENTITIES='ContactType Country Dedupe Domain StateProvince' \ CIVICRM_UF=UnitTests \ phpunit5 \ --stop-on-failure --tap \ tests/phpunit/api/v3/SyntaxConformanceTest.php \ --filter '(testCustomDataGet|testLimit|testSqlOperators)' ``` 5. The reproducibility differed on two laptops. The laptops were largely identical wrt PHP/MySQL binaries+configuration (macOS, bknix@master-loco, `min` cfg). They differed in OS version and hardware specs. The slower machine (low-wattage 2-core CPU; 8gb; Mojave) produced test-failures much more reliably than the faster machine (high-wattage 4-core CPU; 16gb; Sierra). Rationalizations for why it's OK to sip: * The test will continue to be monitored on MySQL 5.7+. * The test *does* pass reliably when run by itself on MySQL 5.5. * [Civi doesn't officially support MySQL 5.5](https://docs.civicrm.org/sysadmin/en/latest/requirements/#mysql-version), so we're not required to faff-about over a failure that only occurs on MySQL 5.5. See also: https://chat.civicrm.org/civicrm/pl/s7nbkro8yjfgzk5z4epo8g9jph
magnolia61
pushed a commit
to magnolia61/civicrm-core
that referenced
this pull request
Oct 13, 2019
…QL 5.5 Overview -------- This disables a particularly flaky test-scenario. Technical Details ----------------- The `SyntaxConformanceTest::testSqlOperators()` has been rather flaky for a while. (I think this goes back either to the creation of the test or the expansion of Dedupe API -- in other words, the test of this scenario has always been flaky.) When the test fails, it looks like this: ``` api_v3_SyntaxConformanceTest::testSqlOperators with data set civicrm#28 ('Dedupe') incorrect count returned from Dedupe getcount Failed asserting that 0 matches expected 2. /home/jenkins/bknix-min/build/build-1/web/sites/all/modules/civicrm/Civi/Test/Api3TestTrait.php:191 /home/jenkins/bknix-min/build/build-1/web/sites/all/modules/civicrm/tests/phpunit/api/v3/SyntaxConformanceTest.php:1131 /home/jenkins/bknix-min/build/build-1/web/sites/all/modules/civicrm/tests/phpunit/CiviTest/CiviUnitTestCase.php:215 /home/jenkins/bknix-min/civicrm-buildkit/extern/phpunit6/phpunit6.phar:570 ``` I've spent a chunk of time investigating the flakiness and found: 1. The test usually (possibly always?) passes on MySQL 5.7. 2. The test often (but not always) fails on MySQL 5.5. 3. The version of PHP (php70 vs php72) does not make much difference. 4. The test never seems to fail when run by itself. The smallest scenario which seemd to reliably produce the failure was: ``` env SYNTAX_CONFORMANCE_ENTITIES='ContactType Country Dedupe Domain StateProvince' \ CIVICRM_UF=UnitTests \ phpunit5 \ --stop-on-failure --tap \ tests/phpunit/api/v3/SyntaxConformanceTest.php \ --filter '(testCustomDataGet|testLimit|testSqlOperators)' ``` 5. The reproducibility differed on two laptops. The laptops were largely identical wrt PHP/MySQL binaries+configuration (macOS, bknix@master-loco, `min` cfg). They differed in OS version and hardware specs. The slower machine (low-wattage 2-core CPU; 8gb; Mojave) produced test-failures much more reliably than the faster machine (high-wattage 4-core CPU; 16gb; Sierra). Rationalizations for why it's OK to sip: * The test will continue to be monitored on MySQL 5.7+. * The test *does* pass reliably when run by itself on MySQL 5.5. * [Civi doesn't officially support MySQL 5.5](https://docs.civicrm.org/sysadmin/en/latest/requirements/#mysql-version), so we're not required to faff-about over a failure that only occurs on MySQL 5.5. See also: https://chat.civicrm.org/civicrm/pl/s7nbkro8yjfgzk5z4epo8g9jph
kcristiano
added a commit
to kcristiano/civicrm-core
that referenced
this pull request
Jun 29, 2020
Failure is due to 'Undefined class constant 'POST_SELECT_QUERY' see https://lab.civicrm.org/dev/joomla/-/issues/28
seamuslee001
added a commit
that referenced
this pull request
Jun 29, 2020
dev/joomla/#28 5.27 Upgrade fails
This was referenced Jan 4, 2024
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.