hpi-swa / smalltalkCI

Framework for testing Smalltalk projects with GitHub Actions, GitLab CI, Travis CI, AppVeyor, and others.
MIT License
94 stars 68 forks source link

add Pharo13 support #639

Closed estebanlm closed 3 months ago

estebanlm commented 4 months ago

we are about to release Pharo12, which means we need to open Pharo13 :)

theseion commented 4 months ago

Looks good, except for the 404 from the file server.

estebanlm commented 4 months ago

yes, I made the PR before having the images :P can you re-trigger it ?

theseion commented 4 months ago
Preparing Pharo image...
Unsupported Pharo version 'Pharo64-13'.
Downloading Pharo64-13 vm...
download_file() expects an URL and a target path.
Error: Process completed with exit code 1.
fniephaus commented 4 months ago

Unsupported Pharo version 'Pharo64-13'.

@estebanlm please also update pharo::get_vm_url()

estebanlm commented 4 months ago

I have no idea what is happening now :)

theseion commented 4 months ago

The specification is good now, IMO. I need to look into the failures coming from SmalltalkCI.

theseion commented 4 months ago

Some of the tests fail due to issues with package management, even in Pharo12-stable. That's odd because I had fixed all of that once already. @estebanlm I'd appreciate it if you could help out with those test failures (or @jecisc maybe). From a quick glance it looks like there's some confusion of tags / categories.

theseion commented 4 months ago

Nvm, I figured it out. @fniephaus the last failing test (#testReportFailure) fails due to different ordering of tests, which leads to different output strings. Also, the fixtures appear to be outdated. I don't see a good way to make that test stable to be honest, the fact that it has worked for so long is a miracle...

theseion commented 4 months ago

I spent 30 minutes trying to clean up the stdout reporter tests and then gave up. To properly match the generated output, we'd either have to use a custom runner or implement templating and complex matching. I don't think it's worth the effort. I've removed the test.

theseion commented 4 months ago

Currently, the GemStone builds are failing and I can't debug those. @fniephaus, can you help out?

fniephaus commented 4 months ago

I spent 30 minutes trying to clean up the stdout reporter tests and then gave up. To properly match the generated output, we'd either have to use a custom runner or implement templating and complex matching. I don't think it's worth the effort. I've removed the test.

Could we relax the test, for example, by ensuring every line from the template can be found in the generated output?

fniephaus commented 4 months ago

Currently, the GemStone builds are failing and I can't debug those. @fniephaus, can you help out?

It seems hdiutil is failing for some reason:

UserDefinedError: The command '/usr/bin/hdiutil attach GemStone64Bit3.5.3-arm64.Darwin.dmg' exited with status 1. See the file '/tmp/gsd_stones139996781290505153618979304401482798518.err'

Maybe the .err file would provide us with more details but this really is something @dalehenrich needs to help us with. In the meantime, I think it's ok to mark the failing GemStone builds as allowed to fail.

theseion commented 4 months ago

Could we relax the test, for example, by ensuring every line from the template can be found in the generated output?

I tried that. Unfortunately, the output includes stuff that I'm sure will differ on other platforms. Example:


#################################################
# Stdout-testReportFailure                      #
# 8 Tests with 4 Failures and 1 Errors in 0.02s #
#################################################

(3 tests passed)

SCIExcludedTests
 ✓ #testDeprecation (0ms)
 ✓ #testShouldPass (0ms)
 ✓ #testShouldFail (1ms)

#########################
# 5 tests did not pass: #
#########################

SCIExcludedTests
 ✗ #testThisIsAVeryLongMethodNameThat...playedCorrectlyInATravisLog (7ms)
TestFailure: Assertion failed
SCIExcludedTests(TestAsserter)>>assert:description:resumable:
SCIExcludedTests(TestAsserter)>>assert:description:
SCIExcludedTests(Object)>>assert:
SCIExcludedTests>>testThisIsAVeryLongMethodNameThatProbablyNeedsToBeContractedInOrderToBeDisplayedCorrectlyInATravisLog ...assert: false
SCIExcludedTests(TestCase)>>performTest
 ✗ #testShouldPassUnexpectedly (0ms)
TestFailure: Test passed unexpectedly ✗ #testError (1ms)
Error: An error message.
SCIExcludedTests(Object)>>error:
SCIExcludedTests>>testError ...error: 'An error message.'
SCIExcludedTests(TestCase)>>performTest
 ✗ #testFailure (1ms)
TestFailure: A failure message.
SCIExcludedTests(TestAsserter)>>assert:description:resumable:
SCIExcludedTests(TestAsserter)>>assert:description:
SCIExcludedTests(TestAsserter)>>fail:
SCIExcludedTests>>testFailure ...fail: 'A failure message.'
SCIExcludedTests(TestCase)>>performTest
 ✗ #testAssertError (1ms)
TestFailure: Got 3 instead of 4.
SCIExcludedTests(TestAsserter)>>assert:description:resumable:
SCIExcludedTests(TestAsserter)>>assert:description:
SCIExcludedTests(TestAsserter)>>assert:equals:
SCIExcludedTests>>testAssertError ...assert: 3 equals: 4
SCIExcludedTests(TestCase)>>performTest


###########
# Summary #
###########

SCIExcludedTests
 ✗ #testThisIsAVeryLongMethodNameThatProbablyNeedsToBeContractedInOrderToBeDisplayedCorrectlyInATravisLog (7ms)
 ✗ #testShouldPassUnexpectedly (0ms)
 ✗ #testError (1ms)
 ✗ #testFailure (1ms)
 ✗ #testAssertError (1ms)

smalltalkCI Deprecation Warnings
 - SCIExcludedTests>>testDeprecation (This is just a test)

  Executed 8 Tests with 4 Failures and 1 Errors in 0.02s.

Fixture:

failureFixtureNonTravis
    ^ '
###############
# Stdout-testReportFailure#
# 8 Tests with 4 Failures and 1 Errors in s #
###############

(3 tests passed)

SCIExcludedTests
 ✓ #testDeprecation (ms)
 ✓ #testShouldFail (ms)
 ✓ #testShouldPass (ms)

#########################
# 5 tests did not pass: #
#########################

SCIExcludedTests
 ✗ #testAssertError (ms)
 ✗ #testError (ms)
 ✗ #testFailure (ms)
 ✗ #testShouldPassUnexpectedly (ms)
 ✗ #testThisIsAVeryLongMethodNameThat...playedCorrectlyInATravisLog (ms)

###########
# Summary #
###########

SCIExcludedTests
 ✗ #testAssertError (ms)
 ✗ #testError (ms)
 ✗ #testFailure (ms)
 ✗ #testShouldPassUnexpectedly (ms)
 ✗ #testThisIsAVeryLongMethodNameThatProbablyNeedsToBeContractedInOrderToBeDisplayedCorrectlyInATravisLog (ms)
smalltalkCI Deprecation Warnings
 - SCIExcludedTests>>testDeprecation (This is just a test)

  Executed 8 Tests with 4 Failures and 1 Errors in s.

'

As you can see, the current result includes stack information and other strings that are not part of the fixture.

estebanlm commented 3 months ago

I do not understand. Anything I should do?

theseion commented 3 months ago

No, I need a decision from @fniephaus on how to proceed.

fniephaus commented 3 months ago

As you can see, the current result includes stack information and other strings that are not part of the fixture.

Sure, makes sense. Could the fixture just be an order-independent subset of the expected output? Something like a list of substrings that must be found in the output.

theseion commented 3 months ago

That sounds feasible, yes.

fniephaus commented 3 months ago

Hope it's not too much work, otherwise I'm ok with disabling/removing the test.

theseion commented 3 months ago

I have a working solution. Can you get me the current output for Travis? Or should we just skip the test for Travis?

fniephaus commented 3 months ago

Cool! Feel free to skip the test on Travis. It's not even set up anymore I think.

theseion commented 3 months ago

@fniephaus I give up. I had it and then GemStone got in the way with a failing implementation of String>>#match: (possibly because of WideString) before I discovered that in Pharo 12 sometimes a new line is missing. There's just too much that can go wrong. IMO, at this point the test would be pretty much useless because it has to incorporate too many exceptions. I've removed it now.

fniephaus commented 3 months ago

Ok, thanks for trying anyway! So this is good to go now from your perspective?

theseion commented 3 months ago

Ok, thanks for trying anyway! So this is good to go now from your perspective?

Yes, looks good (with the exception of the GemStone macOS builds).

theseion commented 3 months ago

I'll squash before merging.

theseion commented 3 months ago

The Pharo64-6.1 on windows-2019 job failed to upload coverage results (the job didn't fail). Do you consider that an issue @fniephaus?

Uploading coverage results to Coveralls...
Failed to upload coverage results (HTTP status code #500):
{"message":"Build processing error.","error":true,"url":""}
fniephaus commented 3 months ago

If it fails the build, I guess it's a bug. But nothing that needs to be addressed in this PR. Don't want to delay this any further :)

theseion commented 3 months ago

Now it looks good. I had to adjust the timeout for Squeak trunk on macOS. For some reason, each stop / start cycle of the images takes multiple minutes.

I can't merge btw, don't have the permission.

fniephaus commented 3 months ago

I can't merge btw, don't have the permission.

That's weird, you do have write permissions which should include permission to merge PRs.

fniephaus commented 3 months ago

Oh, did we just deploy this on a Friday :crossed_fingers: :wink:

theseion commented 3 months ago

IT'S GOING TO BE FINE! 😅

jecisc commented 3 months ago

I wonder if something is missing because we still have this in the CI:

Starting Pharo build...
Unsupported Pharo version 'Pharo64-13'.
Downloading Pharo64-13 image...
download_file() expects an URL and a target path.
Error: Process completed with exit code 1.
theseion commented 3 months ago

Where are you seeing this?

jecisc commented 3 months ago

In most external projects of Pharo. Example:

https://github.com/pharo-spec/NewTools/pull/753/checks

theseion commented 3 months ago

That's because there is no Pharo64-13. Use Pharo64-alpha instead. This is a deliberate choice. With Pharo 12, the image at .../120 was always stale. So while the expectation was that Pharo64-alpha = Pharo64-12, this wasn't true and led to some weird issues. We will add Pharo64-13 before it is released.

estebanlm commented 3 months ago

That's because there is no Pharo64-13. Use Pharo64-alpha instead. This is a deliberate choice. With Pharo 12, the image at .../120 was always stale. So while the expectation was that Pharo64-alpha = Pharo64-12, this wasn't true and led to some weird issues. We will add Pharo64-13 before it is released.

I am sorry but I disagree with that choice. If ../120 (get-files?) was stale there was a problem there, but I do not see why we need to remove the naming for that (which poses some problems in our flow, also).

theseion commented 3 months ago

Ok, I'll add entries for Pharo 13. I'll be counting on your help when stuff breaks ;)