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

codebuild: LinuxBuildImage enum does not resolve correctly #1027

Closed
Stephen-Meyerhofer opened this issue Oct 27, 2018 · 5 comments · Fixed by aws/jsii#291
Closed

codebuild: LinuxBuildImage enum does not resolve correctly #1027

Stephen-Meyerhofer opened this issue Oct 27, 2018 · 5 comments · Fixed by aws/jsii#291
Assignees
Labels
bug This issue is a bug. language/dotnet Related to .NET bindings

Comments

@Stephen-Meyerhofer
Copy link

Amazon.CDK.AWS.CodeBuild.LinuxBuildImage.UBUNTU_14_04_DOTNET_CORE_2_1 resolves to "aws/codebuild/ubuntu-base:14.04" instead of "aws/codebuild/dot-net:core-2.1"

@RomainMuller RomainMuller added bug This issue is a bug. language/dotnet Related to .NET bindings labels Oct 29, 2018
@RomainMuller
Copy link
Contributor

I am unable to reproduce the bad behavior using the TypeScript bindings, so it would appear to be an issue either in the .NET bindings specifically, or in jsii generally.

@RomainMuller
Copy link
Contributor

Good (well, kind of) news! I can reproduce the issue on the .NET runtime, minimal repro:

using Amazon.CDK;
using Amazon.CDK.AWS.CodeBuild;

namespace Repro1027
{
    class Program
    {
        static void Main(string[] args)
        {
            var app = new App();
            var stack = new Stack(app, "TestStack", new StackProps());

            new Project(stack, "CodeBuild", new ProjectProps
                {
                    Environment = new BuildEnvironment { BuildImage = LinuxBuildImage.UBUNTU_14_04_DOTNET_CORE_2_1 }
                }
            );

            app.Run();
        }
    }
}

@RomainMuller
Copy link
Contributor

RomainMuller commented Oct 29, 2018

The JSII_DEBUG trace shows intriguing entries:

< {"callback":{"cbid":"jsii::callback::10033","get":{"objref":{"$jsii.byref":"Object@10005"},"property":"environment"}}}
> {"complete":{"api":"complete","cbid":"jsii::callback::10033","error":"System.ArgumentException: Could not infer JSII type for .NET type 'BuildEnvironment'\nParameter name: type\n   at Amazon.JSII.Runtime.Services.Converters.FrameworkToJsiiConverter.InferType(IReferenceMap referenceMap, Type type)\n   at Amazon.JSII.Runtime.Services.Converters.ValueConverter.ConvertAny(IReferenceMap referenceMap, Object value)\n   at Amazon.JSII.Runtime.Services.Converters.ValueConverter.TryConvertPrimitive(IReferenceMap referenceMap, Object value, Boolean isOptional, PrimitiveType primitiveType, Object& result)\n   at Amazon.JSII.Runtime.Services.Converters.ValueConverter.TryConvert(TypeReference typeReference, IReferenceMap referenceMap, Object value, Object& result)\n   at Amazon.JSII.Runtime.CallbackExtensions.InvokeCallback(Callback callback, IReferenceMap referenceMap, IFrameworkToJsiiConverter converter, String& error)"}}

Apparently, the .NET JSII runtime is unable to determine the native type for the BuildEnvironment class, and this causes it to be understood as undefined, hence the build environment is always the default one.

@RomainMuller
Copy link
Contributor

A part of the problem is aws/jsii#285, where another issue (which I am yet to put my finger on) in JSII should have made your CDK App crash instead of returning incorrect results.

@RomainMuller RomainMuller self-assigned this Oct 30, 2018
@RomainMuller
Copy link
Contributor

I reckon I've identified the bug in the C# JSII runtime that causes the incorrect behavior (aws/jsii#290).

RomainMuller added a commit to aws/jsii that referenced this issue Nov 2, 2018
The `jsii` compiler incorrectly mapped types homonym with a standard
type (`String`, `Number`, ...) to the primitive type on usage sites.
This commit corrects this behavior and adjusts the C# tests accordingly.

Additionally, when the return type of a callback was an interface, the
C# runtime was unable to determine the correct JSII type to use, despite
it has the information on the type of the callback method available. The
resolution behavior has also been fixes, as well as a couple of other
glitches that became apparent as a result of the `Number` type starting
to be correctly represented as the `@scope/jsii-calc-lib.Number` type.

Fixes aws/aws-cdk#1027
RomainMuller added a commit to aws/jsii that referenced this issue Nov 2, 2018
Use the type data available on the deputy object to determine the
relevant JSII type for the result of callbacks, instead of trying to map
into `PrimitiveType.Any`.

Fixes #290
Fixes aws/aws-cdk#1027
RomainMuller added a commit to aws/jsii that referenced this issue Nov 2, 2018
The `jsii` compiler incorrectly mapped types homonym with a standard
type (`String`, `Number`, ...) to the primitive type on usage sites.
This commit corrects this behavior and adjusts the C# tests accordingly.

Additionally, when the return type of a callback was an interface, the
C# runtime was unable to determine the correct JSII type to use, despite
it has the information on the type of the callback method available. The
resolution behavior has also been fixes, as well as a couple of other
glitches that became apparent as a result of the `Number` type starting
to be correctly represented as the `@scope/jsii-calc-lib.Number` type.

Fixes #290
Fixes aws/aws-cdk#1027
RomainMuller added a commit to aws/jsii that referenced this issue Nov 5, 2018
The `jsii` compiler incorrectly mapped types homonym with a standard
type (`String`, `Number`, ...) to the primitive type on usage sites.
This commit corrects this behavior and adjusts the C# tests accordingly.

Additionally, when the return type of a callback was an interface, the
C# runtime was unable to determine the correct JSII type to use, despite
it has the information on the type of the callback method available. The
resolution behavior has also been fixes, as well as a couple of other
glitches that became apparent as a result of the `Number` type starting
to be correctly represented as the `@scope/jsii-calc-lib.Number` type.

Fixes #290
Fixes aws/aws-cdk#1027
RomainMuller added a commit to aws/jsii that referenced this issue Nov 6, 2018
The `jsii` compiler incorrectly mapped types homonym with a standard
type (`String`, `Number`, ...) to the primitive type on usage sites.
This commit corrects this behavior and adjusts the C# tests accordingly.

Additionally, when the return type of a callback was an interface, the
C# runtime was unable to determine the correct JSII type to use, despite
it has the information on the type of the callback method available. The
resolution behavior has also been fixes, as well as a couple of other
glitches that became apparent as a result of the `Number` type starting
to be correctly represented as the `@scope/jsii-calc-lib.Number` type.

Fixes #290
Fixes aws/aws-cdk#1027
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. language/dotnet Related to .NET bindings
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants