-
-
Notifications
You must be signed in to change notification settings - Fork 851
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
enable using github actions for build #1061
Conversation
+ publish to github package repository
Codecov Report
@@ Coverage Diff @@
## master #1061 +/- ##
==========================================
- Coverage 87.44% 83.71% -3.73%
==========================================
Files 1131 688 -443
Lines 50041 28853 -21188
Branches 3677 0 -3677
==========================================
- Hits 43756 24155 -19601
+ Misses 5534 4698 -836
+ Partials 751 0 -751
Continue to review full report at Codecov.
|
I'm super excited about this! We can finally target NET Core 3+ I'll have a proper dig through the config as soon as I can. Only question I have straight away is that I can only see a subset of the original target frameworks from AppVeyor. Is that intentional? |
It was somewhat intentional, removing the net642 targets was intentional they are so old i feel we can just drop version/target now. Totally forgot about x86 netcore and also mono. |
It was somewhat intentional, removing the net642 targets was intentional they are so old i feel we can just drop version/target now. Totally forgot about x86 netcore and also mono. I guess I'm ok with that considering the warning regarding NET 4.6x from the docs
I'm curious to see how fast the builds/tests are on here though with the full suite as they seem to be rocket powered looking at the individual numbers. |
I really want to do a deeper review on this during the weekend. For now, only one comment: |
…eSharp into sw/github-actions
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.
looks good to me, good job @tocsoft and @JimBobSquarePants
There are massive changes that may effect local dev experience. Gonna check the branch tonight with Rider. |
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.
Great job with the CI! 🎉
But I have to disagree with the sudden introduction of StyleCop in tests. Having 7632 😱 warnings completely hangs my Rider, making it impossible to edit stuff.
We should introduce rules incrementally in separate PR-s, including fixes for the rules being introduced.
You and your toy IDE 😝 It’s a blanket off and on case with stylecop. You have to specify the rules and turn them off individually. I’ll disable for now in tests and re-add them with another PR fixing them. It would only take me a couple of hours. |
Im not sure if, we should enable stylecop rules in tests at all. Myself i would not care about it, but i had some colleagues in the past who really disliked those rules. I think writing tests is a chore by itself and we should not make it harder by enforcing style rules on them. I think its ok, if its a bit of a wild west in the tests. |
The rules are much less strict than the main src and we can tweak them as need be. We need something though. The tests are difficult to follow at points which is dangerous. |
ok then, if you want i can do that. I have some free time next week, i would not mind to do that. |
I think even relaxed ruleset is worth a review to make sure they don't harm readability by eg. enforcing rules on Member Data formatting which are impractical here. (There might be no such case in practice - just an example to emphasize that we should be careful.) Fortuanately StyleCop's automatic formatters seem to work much better today (at least with Rider). A few years ago, when I had to fix everything manually, it was a terrible & frustrating productivity killer for me. I used to fight until my last blood to keep SC far from the test code 😄 |
codecov: false | ||
- os: windows-latest | ||
framework: netcoreapp3.1 | ||
runtime: -x64 |
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's worth to also test x86 + 3.1 because of the floating point magic we do.
Prerequisites
Description
Adds a github workflow for building PRs using github actions and also build master branch on tags and merges.
On merges/tags packages are built and uploaded to github pacakge repository & for the time being myget (that can be phased out in the future are required.)
Known differences
Package number changes - due to the fact that github doesn't have build numbers we are generating the number from the date/time of the commit being built which should be unique and sequential enough for our use case.
As part of this PR i've also stopped Appveyor from publishing to the myget feed so we don't get a strange mix of packages up there.
Update
@JimBobSquarePants (me) added additional changes.
netcorapp3.1
,netstandard2.1
and set langversion to 8net462
target from tests and addednetcoreapp3.1