-
Notifications
You must be signed in to change notification settings - Fork 189
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
GitHub CI #1106
GitHub CI #1106
Conversation
Nice, thank you so much! I guess this won't actually run anything until it's merged? |
I just forgot to add a pull request trigger so nothing ran when I opened it. It seems to have kicked into action now. |
I've split the existing github actions script for packaging back into its own file. So thats now the same as the one in master with the only change being it now only runs on pushes to master, which is probably along the lines of the original intention of it. One new development is that haxe nighlies no longer seem to work on osx? The setup haxe action always fails when it tries to setup haxelib, it complains about not being able to find libneko.
@tobil4sk you've been doing some haxelib and neko packaging stuff, right? Anything changed fairly recently which could cause this? Not sure if this is a problem with the haxe setup action, haxelib, neko, or something else... |
I think this is due to HaxeFoundation/haxe#11653. Previously the haxelib binary had the same rpath as the neko binary, which included @loader_path. However, now the haxelib binary is built with its own rpath which does not include this. This is why it is failing to find libneko. I'm not sure if the binaries are intended to be installed the way that setup-haxe is doing it. This can be fixed either by adding the rpath to the haxelib binary or by changing setup-haxe to install the binaries to a default loader path ( |
Thanks, I'll have a look at haxe setup and see if I can update it. |
Getting neko to work again was as simple as ensuring I think this is good to go now, but we might want to wait for those to get merged and have a new setup-haxe release instead of it pointing to a commit in my fork. |
I feel like there has been enough waiting, we can always update this later if those PRs get merged. Thank you! |
Been wanting this for a while since forks don't inherit azure pipeline stuff, so here's the existing azure pipeline CI ported to github actions. Main changes are as follows;
Example of what a branch of mine looks like, all those tags were generated by the CI.
Some small things I've noticed, the "haxe" tests for 32bit windows take an age to run (15mins vs 5mins for 64bit Windows and other OS'). Building the haxe repo test suite also takes 16mins on Mac vs ~4mins on Windows and Linux.