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

Bump target frameworks of C# programs from netcoreapp1.0 to netcoreapp2.1 #5838

Merged

Conversation

ObsidianMinor
Copy link
Contributor

Moved global.json up to root of repo, changed SDK version to 2.2.100.
Changed .NET Core SDK in dockerfile for kokoro to version 2.2.100.

.NET Core 1.0 is reaching end of life, it's hard to install, and it's getting in the way of everyone's fun.

This should fix issues with #5802

Move global.json up to root of repo, change SDK ver to 2.2.100
Change .net core sdk in dockerfile for kokoro to ver 2.2.100
@ObsidianMinor
Copy link
Contributor Author

@acozzette can you run a kokoro build to make sure this works?

@acozzette
Copy link
Member

Sure, I just added the tag to start the build.

@jtattermusch
Copy link
Contributor

@ObsidianMinor ObsidianMinor changed the title Bump target frameworks of C# programs from netcoreapp1.0 to netcoreapp2.2. Bump target frameworks of C# programs from netcoreapp1.0 to netcoreapp2.1 Mar 6, 2019
@jtattermusch
Copy link
Contributor

I pushed a few more changes to this PR - basically introducing a separate Dockerfile for C# tests (which seems to be in alignment with what protobuf team has been striving to do) - I was getting errors when re-building the multi-language Dockerfile

@jtattermusch
Copy link
Contributor

@@ -316,7 +316,7 @@ conformance-java-lite: javac_middleman_lite
conformance-csharp: $(other_language_protoc_outputs)
@echo "Writing shortcut script conformance-csharp..."
@echo '#! /bin/sh' > conformance-csharp
@echo 'dotnet ../csharp/src/Google.Protobuf.Conformance/bin/Release/netcoreapp1.0/Google.Protobuf.Conformance.dll "$$@"' >> conformance-csharp
@echo 'dotnet ../csharp/src/Google.Protobuf.Conformance/bin/Release/netcoreapp2.1/Google.Protobuf.Conformance.dll "$$@"' >> conformance-csharp
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Why do we call the dll directly instead of dotnet run --no-build?

Copy link
Contributor

Choose a reason for hiding this comment

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

I personally feel more confident that this will really only run the pre-built dll as opposed to to running a dotnet command that can potentially do something extra. No reason to change this in this PR.

@jtattermusch
Copy link
Contributor

I pushed the new testing image for C#, restarting tests.

@jtattermusch
Copy link
Contributor

The new docker image seems to be working fine, but the c# compatibility test is now failing with
https://source.cloud.google.com/results/invocations/95f1e9c3-988e-46b3-9875-ec63b2cd6564/log. Any idea what's wrong? Help is appreciated.

+ cp ../../../src/protoc protoc_1
+ cp old_protoc protoc_2
+ run_test
+ ./protoc_1 -Iprotos/src -I../../../src/ --csharp_out=src/Google.Protobuf.Test --csharp_opt=base_namespace=Google.Protobuf protos/src/google/protobuf/unittest_import_proto3.proto protos/src/google/protobuf/unittest_import_public_proto3.proto protos/src/google/protobuf/unittest_well_known_types.proto
./protoc_1: error: '/tmp/protobuf/protobuf/csharp/compatibility_tests/v3.0.0/.libs/protoc' does not exist
This script is just a wrapper for protoc.
See the libtool documentation for more information.
+ FAILED=true
+ docker rm -f build_and_run_docker_490e5066-dae0-49b4-8620-d4d8d44a628d
build_and_run_docker_490e5066-dae0-49b4-8620-d4d8d44a628d
+ '[' -z true ']'
+ exit 1
[ID: 7381063] Build finished after 273 secs, exit value: 1

@@ -0,0 +1,36 @@
FROM debian:stretch
Copy link
Contributor Author

@ObsidianMinor ObsidianMinor Mar 7, 2019

Choose a reason for hiding this comment

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

Original was debian:latest, why change it to stretch? Could this cause the issues we're seeing with compatibility testing?

Copy link
Contributor

Choose a reason for hiding this comment

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

currently latest = stretch, but meaning of debian:latest can change over time, and the idea of the docker image is to provide a stable runtime environment, so pinning to a specific version seems as a logical choice.
In the past, when debian:lastest changed from jessie to streche, that broke many of our dockerfiles.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The only difference I can see between the last successful run I can find (22 days ago) and this one is that the base image was updated from Debian 9.7 to 9.8 but I don't know if that's the issue (I highly doubt it is).

We could just change the script to use path variables rather than copying files. I believe it'd easier to understand and manage that way in the long run.

@ObsidianMinor
Copy link
Contributor Author

Try the tests one more time @jtattermusch

@jtattermusch
Copy link
Contributor

the required dotnet SDK was not available on Kokoro Windows workers, so I added a script to install the right version of SDK before starting a windows build.
5e3e9fb

@jtattermusch
Copy link
Contributor

I think the PR is ready for review and merging now.
Please doublecheck the sanity of changes to the compatibility script in
0efbd9a while reviewing.

@anandolee anandolee merged commit 15fab91 into protocolbuffers:master Mar 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants