Skip to content
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

Merged
merged 2 commits into from
Feb 8, 2021

Conversation

stakx
Copy link
Member

@stakx stakx commented Jan 12, 2021

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.)

  • Running our ExplicitVersions tool to sync the auxiliary packages' versions with the main package's version.
  • Anything else NuGet deployment related.
  • Further tests to ensure that the build fails under certain conditions:
    - failed unit test
    - failed PEVerify execution
  • Structuring the workflow definition file a little nicer
  • Possibly separating this commit into several commits

@stakx stakx marked this pull request as draft January 12, 2021 23:51
Copy link
Member

@jonorossi jonorossi left a 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.

README.md Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
.github/workflows/build.yml Outdated Show resolved Hide resolved
@stakx stakx force-pushed the github-actions branch 2 times, most recently from e47d84f to 141c196 Compare February 6, 2021 19:28
@stakx stakx marked this pull request as ready for review February 6, 2021 19:36
@stakx
Copy link
Member Author

stakx commented Feb 6, 2021

@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.)

Copy link
Member

@jonorossi jonorossi left a 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.

@stakx stakx merged commit a191863 into castleproject:master Feb 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants