Update binlog path. #6
Conversation
This fails to run because `build` exists an a bash script in the `nunit-console` root, so trying to create a file in `build\NUnitConsole.binlog` fails. I missed this in my testing because I made the change as an afterthought to try and avoid needing to modify the `.gitignore` file. `build/` is ignored by default so I figured that'd be a good place to put it without even thinking to try it out.☹️ I used `build-results` to parallel `test-results` which is currently used for all test output, but we can put it wherever. I'll update the `.gitignore` with this folder.
|
This is a reasonably trivial change, so I'm committing it to unblock testing on |
|
Hmm... the AppVeyor Build is still not running at all when you merge into main. I'll look at the settings. |
|
It was disabled. Fixed and triggered manually. FYI there were problems with AppVeyor building PRs. Next new PR will tell us if those are fixed. |
| @@ -196,7 +196,7 @@ public static class BuildSettings | |||
| BinaryLogger = new MSBuildBinaryLoggerSettings | |||
| { | |||
| Enabled = true, | |||
| FileName = "build/NUnitConsole.binlog", | |||
| FileName = "build-results/NUnitConsole.binlog", | |||
There was a problem hiding this comment.
Is there ever more than one file here?
There was a problem hiding this comment.
Right now, I don't believe so, but if we have something that locally builds on multiple platforms (maybe using docker or something) the I could imagine having a binlog for each platform.
|
OK... the AppVeyor build failed because the build is trying to produce a new production release for some reason. The package that is created is versioned as 3.18.1, which is actually our last production release. I would have expected it to be BTW, everything that should run runs and passes, so that's good. |
A package called NUnit.Cake.Recipe.1.0.0-veleek-binlog1.nupkg gets created. |
|
OK, I took a look on my Windows VM and I think we are having some versioning issues. I assume you have an The same thing applies in your local copy of nunit.org, except the versions will be different. Probably it would be simpler if you created feature branches under the nunit org rather than on a fork. We usually use names like issue-xxx where there is an issue or something descriptive for simple changes without an issue. But lets get this all merged first. I'm afraid I did leave with the recipe in a bit of an unstable state. I didn't think you would need to change it. So you may find that the |
|
Should there be a dev00003 build published? I checked last night and didn't see one.
Alternatively, are you aware of a way I can build nunit-console using a locally built NUnit.Cake.Recipe package? I assume that I can add a local package source (or just drop the package into my local package chance manually), but I haven't had a chance to try and I don't know if that'll play well with |
|
I just published dev00007 with all your changes so far plus a fix to #7. AppVeyor appears broken. See #8. Meanwhile, I can publish locally but I am not sure you can. You can build and test locally if you have a copies of nunit-console and the cake recipe in sibling directories. See comment at the top of the build.cake file for nunit-console. However, this should not be needed if you use dev00007. I'll be back in action on the weekend. :-) See also email I sent you a little while ago. |
|
@CharliePoole On the other repos we have moved over to only using Github actions. We have dropped both the Azure Devops Pipelines where they were they used, and the appveyor builds. In the NUnit repo there is a yml file for pushing to Myget. It simplified things, and also, we experienced that Appveyor were lagging with updating their servers with the appropriate frameworks. |
|
@OsirisTerje Right, that's one of the things I want to put into the overall plan for CI. I'll try to have a planning session with @veleek this weekend or after. In general, I'd like to get set up so that the windows build under GitHub actions is the one that does the publishing. That said, I have never NOT needed a backup plan, so I wonder if we shouldn't keep AppVeyor running and available. (Currently, the backup is that I publish from my local machine.) |
|
🎉 This issue has been resolved in version 1.1.0 🎉 The release is available on: |
This fails to run because
buildexists an a bash script in thenunit-consoleroot, so trying to create a file inbuild\NUnitConsole.binlogfails.I missed this in my testing because I made the change as an afterthought to try and avoid needing to modify the☹️
.gitignorefile.build/is ignored by default so I figured that'd be a good place to put it without even thinking to try it out.I used
build-resultsto paralleltest-resultswhich is currently used for all test output, but we can put it wherever. I'll update the.gitignorewith this folder.