-
Notifications
You must be signed in to change notification settings - Fork 85
Finish GH Actions migration #399
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Ok, now we just need to get tests to pass again. |
Seems like we may have a flaky test. Running locally, the |
Hey! CI passes now 😄 🎉 |
Now the question is how to add the Windows build back in... |
Windows CI now builds. This PR should be ready for a review. The last few commits were just cleaning up the |
Actually, one other thing we'll need to do here is verify that |
CI builds. This PR is ready for review. If we need to test a new PS version, we can add it pretty easily via the matrix. |
- purs was updated to v0.14.5 - only more recent versions are being tested - psc-package is installed via NPM
c76a8cb
to
3862469
Compare
.github/workflows/ci.yml
Outdated
os: [ubuntu-latest, windows-latest] | ||
PURS_TEST_VERSION: [v0.12.3, v0.12.5] | ||
runs-on: ${{ matrix.os }} | ||
purs_test_version: [v0.14.4, v0.14.5] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether we could get away with only testing against a single PureScript version? In that case we could use setup-purescript
to install the Windows, Linux, and macOS versions of the compiler. For example, you can see that all three are used in the integration test:
https://github.com/purescript-contrib/setup-purescript/blob/main/.github/workflows/integration.yml
That might make these installations a little less involved. Or is there a reason we need to test against multiple versions, or have the distinction between BUILD_VERSION and TEST_VERSION that I'm missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That might make these installations a little less involved. Or is there a reason we need to test against multiple versions, or have the distinction between BUILD_VERSION and TEST_VERSION that I'm missing?
How will we verify that pulp run
works when in one case we're using v0.15.0
and in another we're using v0.14.5
? We need to verify that both versions will work with the same version of pulp
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The distinction exists because the Pulp source code can generally only be compiled by one PureScript compiler version at a time, but the compiled code needs to be tested against multiple compiler versions - the user won’t necessarily be using the same version as the one we used to build Pulp. I think testing against multiple compiler versions is necessary, since pulp is expected to work with multiple compiler versions, and especially since different compiler versions cause different code paths to be taken in pulp. Testing against multiple compiler versions has saved my skin a number of times in the past.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we are no longer testing against 0.12 and 0.13 now, but I’d strongly recommend continuing to test against at least one compiler version from every version series that is still supported by pulp, and in particular to test on the very earliest version that’s still supported. It’s very easy to accidentally depend on a compiler flag that doesn’t exist in all of the supported versions. Dropping support for old versions is also fine but I think it’s important that people who try to use those old versions with the new pulp get reasonable error messages (via the mechanism in Pulp.Validate).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we should continue to support some older compiler versions than what this PR was currently testing. I've added back v0.12.4
and v0.12.5
, which this PR had removed. I've also added v0.13.0
and replaced v0.14.4
with v0.14.0
to see if it triggers any such failures.
I haven't added back in v0.11.0
, but that was because I git push
ed before remembering to add it. I think it's likely save to drop support for that, but I think we should continue to support if its tests still pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something weird is going on here - this doesn’t seem like something that should be happening as pulp doesn’t directly impact the JS the compiler produces. Are the tests perhaps trying to bundle some compiled PureScript code with a different version of purs
than the one that compiled that code somehow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the tests perhaps trying to bundle some compiled PureScript code with a different version of purs than the one that compiled that code somehow?
I believe so. The error itself says
purs bundle "output/*/*.js" --output unit-tests.js --module Test.Main --main Test.Main && node unit-tests.js
so it's bundling output/*/*.js
, which was compiled by the build version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, can we have that purs bundle
command use the build version of purs
rather than the test version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I split the test:unit
part from the test:integration
part, and then had to update the dependencies installed when pulp init
runs.
v0.11.0
still doesn't build for two reasons. First, there's not psc-package
for that release apparently. Second, the code to run uses Effect
, not Eff
. So, I think we should drop it because that will be 4 major releases behind current once v0.15.0
is out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think dropping support for 0.11 is totally reasonable.
Last few commits are to clean up the imports and warnings so future PRs have less noise going on. |
7e5c235
to
3eaf9f2
Compare
2259d15
to
eb1ee70
Compare
CI now builds on |
Do I need to add an entry to the changelog in this PR? Or will we do that in the release? |
os: [ubuntu-latest, windows-latest] | ||
PURS_TEST_VERSION: [v0.12.3, v0.12.5] | ||
runs-on: ${{ matrix.os }} | ||
purs_test_version: [v0.12.0, v0.12.4, v0.12.5, v0.13.0, v0.14.0, v0.14.5] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be nice to pull this out so that it can be reused by both the windowsBuild and the nonWindowsBuild, so that the test versions can't get out of sync between the windows and non-windows builds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would, but it's not clear to me how to do that. I could use one build and then use a lot of if: runner.os != 'Windows'
conditions, but I didn't like that. So, I split it into two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤷♂️ I merged them back into one build because I did make the mistake of only updating one of those arrays in #401.
#398 wasn't triggering CI because the PR was coming from outside of the repo, so it got merged. However, that PR introduced another .yml file that wasn't needed. This removes it.