-
Notifications
You must be signed in to change notification settings - Fork 471
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
Run build and tests on GitHub Actions #559
Conversation
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'm happy with the direction. I wouldn't mind if this goes in sooner rather than later, even if we still release from AppVeyor for now. That allows us to add to it over time and transition when ready.
e47d84f
to
141c196
Compare
@jonorossi, I've been able to improve on the issues you raised above. Still far from complete, but reasonably clean now. I'm definitely skipping a few things (for instance: versioning, and publishing packages) at this time: It appears that Appveyor is currently both faster and more reliable overall than GitHub Actions. With the latter, I've witnessed several random workflow failures e.g. because of intermittent network connection break-offs. It would perhaps be prudent to gain some more everyday experience with GitHub Actions in this project before going all in and abandoning Appveyor. (That being said, I do still think that GitHub Actions is a step in the right direction.) |
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.
Unfortunate to hear about broken network connections, is that connecting to nuget.org I've not had any random failures on a Windows instance of GitHub Actions I'm using for a private project, however I'm subscribed to GitHub's status page and they've definitely had a lot of outages in the last 1-2 years compared to previously, I think the rapid scale out with growth is a challenge at the moment.
Definitely agree that it would be good get to some more real world experience. Merge if you are ready, this looks great.
Let's get started on migrating our CI build from Appveyor to GitHub Actions (#497). I haven't got very far yet. At the moment, this includes the build and test runs—with the addition of .NET Core test runs on MacOS—but no NuGet deployment-specific build steps.
You can see this in action over at my fork.
I haven't yet found an easy way to only build once, then reuse the build output for different OS builds. The reason is that a build will not copy all required binaries from NuGet packages to the output folder; one would need to
dotnet publish --self-contained
to get complete output. A self-contained publish however produces runtime & platform specific output which is not what we want. Only speeding up the NuGet package restore by caching the package folder across OS builds doesn't help a lot time-wise due to the relatively large data volume (> 0.5 GB). Due to all of this, I suggest we do what's most straightforward and perform a complete restore, build, and test run cycle for every OS.What's still missing? (Feel free to add to this list.)
- failed unit test
- failed PEVerify execution
Possibly separating this commit into several commits