Skip to content
This repository has been archived by the owner on Jul 27, 2019. It is now read-only.

Update framework, consolerunner, and engine #218

Merged
merged 7 commits into from
Sep 7, 2017

Conversation

mikkelbu
Copy link
Contributor

  • NUnit framework updated to 3.7.1
  • NUnit.ConsoleRunner updated to 3.7.0
  • NUnit.Engine updated to 3.7.0

Fixes #199

* NUnit framework updated to 3.7.1
* NUnit.ConsoleRunner updated to 3.7.0
* NUnit.Engine updated to 3.7.0

Fixes #199
@CharliePoole
Copy link
Collaborator

Failing on Travis. If you can get it fixed we can merge, but normally we don't want to arbitrarily update our dependencies. In addition, we wouldn't normally update all these dependencies at the same time or for the same reason.

The engine is our only true dependency. The gui is written assuming certain features in the engine. In theory, the engine is always backwards compatible, but now that this project is separate from the NUnit Project, we need to actually test new engine releases before using them.

The framewok is only a dependency of our tests. We can update the version as needed but it doesn't have anything to do with how the gui works. In fact, it's supposed to work with any framework version.

The console runner is used to run our tests in batch mode. It doesn't affect the gui either although we have to watch out for engine conflicts, since the console runner comes with it's own copy of the engine.

As I said, even though some of this is unnecessary, it can't hurt provided you can get the CI to pass. If not, we can remove whichever upgrade is causing the problem.

@mikkelbu
Copy link
Contributor Author

Originally I just wanted a newer version of the engine, so we could get some better logging for #162, and then I thought that would update it all, as I had to touch the same files (except for the console runner). Also I did not think that it would break anything.

As far as I can tell (by googling the error message from Travis) the problem is that the nuget-client used by the script is too old. The current cake script downloads nuget.exe from https://www.nuget.org/nuget.exe (which is version 2.8.60717.93), but newer cake scripts (like the one used for nunit-console) downloads from https://dist.nuget.org/win-x86-commandline/latest/nuget.exe (which is version 4.1.0.2450). Would it be okay if I also updated the cake bootstrappers (build.ps1 and build.sh) with the newest files?

@CharliePoole
Copy link
Collaborator

That makes sense to me. If necessary, you can update the Cake version as well.

Downloaded new bootstrappers from https://github.com/cake-build/resources
and removed tools/nuget.exe, so a newer version can be downloaded by the
scripts.
@CharliePoole
Copy link
Collaborator

Odd message in travis: "More than one build script specified"

@mikkelbu
Copy link
Contributor Author

Yes I'm looking into it 😟 . I guess that this will take some tries, as I cannot test my changes locally.

@mikkelbu
Copy link
Contributor Author

It is working again 😄 . When updating the bootstrappers to the newest version it required changes in .travis.yml to keep the existing behaviour. I think that the changes from @jnm2 in cake-build/resources#30 required us to change --target "Travis" to -target="Travis" as the build.sh no longer has special handling of --target.

Ps. I've also set configuration and verbosity to keep the original behaviour (these are no longer defaults in the script). While running without verbosity set I noticed the following warnings (see https://travis-ci.org/CharliePoole/nunit-gui/jobs/268152170)

  • WARNING: Error reading msbuild project information, ensure that your input solution or project file is valid. NETCore and UAP projects will be skipped, only packages.config files will be restored.
  • xbuild tool is deprecated and will be removed in future updates, use msbuild instead

I'll create two issues regarding these problems.

PPs. @CharliePoole Is it on purpose that we do not run tests on Travis?

@CharliePoole
Copy link
Collaborator

Frankly, I don't like that change. It goes against standard conventions for use of -- and - in commands. The "special handling" was there to make it work on Linux as Linux command options are supposed to work. However, it's not the only program I've seen that is abandoning the standard approach in favor of one that works the same on Windows and Linux.

Re: Warnings - I was aware of the second but not the first. We shouldn't have any .NET Core in our build.

Re: Tests - I haven't been able to run them in Travis in the past but I'm working on something.

@jnm2
Copy link
Contributor

jnm2 commented Aug 25, 2017

I think that the changes from @jnm2 in cake-build/resources#30 required us to change --target "Travis" to -target="Travis" as the build.sh no longer has special handling of --target.

If that changed, that was not on purpose and I need to get that fixed.

@jnm2
Copy link
Contributor

jnm2 commented Aug 25, 2017

I assumed that cake.exe interpreted -arg and --arg identically on Mono since it does on .NET Framework.

@CharliePoole
Copy link
Collaborator

That's the Cake folks' call, of course. They may want to use something consistent with Powershell in both environments.

@jnm2
Copy link
Contributor

jnm2 commented Aug 25, 2017

Okay right now, --target "Travis" doesn't work but --target="Travis" and --target=Travis do work.

@jnm2
Copy link
Contributor

jnm2 commented Aug 25, 2017

cake-build/resources#33

Copy link
Collaborator

@CharliePoole CharliePoole left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikkelbu I was wondering what had happened to this PR but when I looked at it I saw that my comments are still all pending! I'm making this review a Comment for now so you can read the comments By now I have forgotten myself what they were! Once past that, we can decide what to do next.

@@ -4,5 +4,5 @@ mono:
- latest
- 4.6.2
script:
- ./build.sh --target "Travis"
- ./build.sh -target="Travis" -configuration="Release" -verbosity="verbose"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The use of -- options is normal for non-single-letter options in Linux. I'm surprised the single dash works at all, since --targets is supposed to mean the same as -t -a -r -g -e -t -s in normal use. Has the script changed WRT this?

Copy link
Contributor Author

@mikkelbu mikkelbu Sep 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently, this is due to Mono/Cake. Before the build.sh script did special-handling of, among other, target
https://github.com/NUnitSoftware/nunit-gui/blob/7fb774fc4b5e4e52107bb17a46e30442c38a0cc0/build.sh#L25
(e.g. extracted the value into TARGET and then called Mono/Cake in the end of the script like this
https://github.com/NUnitSoftware/nunit-gui/blob/7fb774fc4b5e4e52107bb17a46e30442c38a0cc0/build.sh#L61
In the version of the script I used, there was no special-handling of target. Hence I had to give the parameters in the syntax that Mono/Cake expects. I think that @jnm2 change above will solve this.

@CharliePoole CharliePoole modified the milestone: 0.6 Sep 7, 2017
Copy link
Collaborator

@CharliePoole CharliePoole left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ready to merge to me if you can resolve conflicts.

@mikkelbu mikkelbu merged commit 5880fff into TestCentric:master Sep 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants