Add support for .NET Core build #80

normj · 2019-02-11T22:46:37Z

Description of changes:
Add support for building .NET Core Lambda function as part of SAM build.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Unzip package zip file Update DESIGN.md

sriram-mv · 2019-02-12T18:14:13Z

aws_lambda_builders/workflows/dotnet_clipackage/DESIGN.md

+      -dvc   | --disable-version-check        Disable the .NET Core version check. Only for advanced usage.
+```
+
+Currently **--framework** is the only required parameter which tells the underlying build process what version of .NET Core to build for.


How is this infomation passed in? is it decided by the builder based on the runtime?

For most users --framework will be already set in the aws-lambda-tools-defaults.json file so they won't have to do anything. If it is not set then the user would need to specify it on the sam build command line which would get passed into the builder. I tried to follow the examples I saw in the other builders for grabbing options that were passed on the commandline.

So this is currently not supported in SAM CLI, although the correct plumbing exists thru options property. See #4

How big of a requirement is this? Do you know the fraction of users that use parameters vs .json file to pass this value?

It is not big requirement since the framework will most likely be set through the *.json file. It is a good thing to have for the future. As long as the code is doing it in the way SAM envisions this being handled in the future is all that I require now. We should make sure SAM init version of a .NET Core project includes the json file like all of the rest of our .NET tooling does.

I also might update the Amazon.Lambda.Tools to auto detect the framework based on the project file. If/when I do this work SAM build would pull that change in automatically due to the nature of this PR always updating the version of Amazon.Lambda.Tools.

Yeah, in the future when we add add sam build --debug mode, we would want to pass this over to lambda-builders, and the dotnet workflow to pick it up as the configuration.

This would also yield a conversation on which is higher priority, the flag or the information in the json config file.

The existing Amazon.Lambda.Tools .NET Core Global tool that this wraps around already has the rule that if a value is specified in the command line it overrides any setting in the json file. I would expect that rule to apply from sam build as well.

sriram-mv · 2019-02-12T18:14:57Z

aws_lambda_builders/workflows/dotnet_clipackage/DESIGN.md

+The tool is installed by executing the command `dotnet tool install -g Amazon.Lambda.Tools` This will install the
+tool from [NuGet](https://www.nuget.org/packages/Amazon.Lambda.Tools/) the .NET package management system. 
+
+To keep the tool updated the command `dotnet tool update -g Amazon.Lambda.Tools` will be executed if the install 


sanathkr · 2019-02-14T16:44:23Z

aws_lambda_builders/workflows/dotnet_clipackage/DESIGN.md

+
+#### Output
+
+The output of `dotnet lambda package` command is a zip archive that consumers can then deploy to Lambda. For SAM build


Yes, this is a requirement mainly stemming from the ability to customize the zip file later during package. See this discussion - #69 (comment)

sanathkr · 2019-02-14T16:46:02Z

aws_lambda_builders/workflows/dotnet_clipackage/DESIGN.md

+      -dvc   | --disable-version-check        Disable the .NET Core version check. Only for advanced usage.
+```
+
+Currently **--framework** is the only required parameter which tells the underlying build process what version of .NET Core to build for.


So this is currently not supported in SAM CLI, although the correct plumbing exists thru options property. See #4

How big of a requirement is this? Do you know the fraction of users that use parameters vs .json file to pass this value?

sriram-mv · 2019-02-15T17:54:23Z

aws_lambda_builders/workflows/dotnet_clipackage/actions.py

+class GlobalToolInstallAction(BaseAction):
+
+    """
+    A Lambda Builder Action which runs bundle install in order to build a full Gemfile.lock


docstring update

sriram-mv · 2019-02-15T17:54:34Z

aws_lambda_builders/workflows/dotnet_clipackage/actions.py

+
+class RunPackageAction(BaseAction):
+    """
+    A Lambda Builder Action which vendors dependencies to the vendor/bundle directory.


docstring update

sriram-mv · 2019-02-15T17:55:34Z

aws_lambda_builders/workflows/dotnet_clipackage/actions.py

+
+    def execute(self):
+        try:
+            LOG.debug("Running bundle install --deployment in %s", self.source_dir)


log statement needs update

sriram-mv · 2019-02-15T17:57:25Z

tests/integration/workflows/dotnet_cli-package/test_dotnet.py

+        self.builder.build(source_dir, self.artifacts_dir, self.scratch_dir,
+                           source_dir,
+                           runtime=self.runtime,
+                           options={"--framework": "netcoreapp2.1", "--configuration": "Debug"})


we currently need a way to support args support in aws-sam-cli, i.e flags passed to sam build

Is it fine to leave this hear till sam build adds support for passing args?

Yeah think thats fine.

sriram-mv · 2019-02-15T17:59:03Z

aws_lambda_builders/workflows/dotnet_clipackage/workflow.py

+    """
+    NAME = "DotnetCliPackageBuilder"
+
+    CAPABILITY = Capability(language="dotnet",


Do we need to add resolver and validator for the executables used by the workflow?

Do you have an example of what you mean?

https://github.com/awslabs/aws-lambda-builders/blob/develop/aws_lambda_builders/workflows/java_gradle/workflow.py#L54

https://github.com/awslabs/aws-lambda-builders/blob/d60920060e2f52688a1b84d8c6d635dd8d4799fc/aws_lambda_builders/workflows/java_gradle/workflow.py#L57

Those are the examples.

I added a resolver to make sure the dotnet CLI is installed.

A validator is not needed because the dotnet CLI has its own built in versioning system to match the available installed .NET SDK with the selected project. A validator would just duplicate that work and possibly get in the way.

sriram-mv

changes to travis might be required to get the tests to pass on linux, to install dotnet executable beforehand.

I see windows is passing! woohoo 💯 , we may still need some more test coverage to get the overall gate to pass though after installing dotnet on the travis boxes.

sriram-mv · 2019-02-21T22:54:50Z

aws_lambda_builders/workflows/dotnet_clipackage/DESIGN.md

+      -dvc   | --disable-version-check        Disable the .NET Core version check. Only for advanced usage.
+```
+
+Currently **--framework** is the only required parameter which tells the underlying build process what version of .NET Core to build for.


Yeah, in the future when we add add sam build --debug mode, we would want to pass this over to lambda-builders, and the dotnet workflow to pick it up as the configuration.

This would also yield a conversation on which is higher priority, the flag or the information in the json config file.

sriram-mv · 2019-02-26T18:14:17Z

This looks good to me! All gates pass. Just a follow up question, do we need a test with any tough to build dependencies in the builder?

sriram-mv · 2019-02-26T18:19:11Z

aws_lambda_builders/workflows/dotnet_clipackage/dotnetcli.py

+        # The package command contains lots of useful information on how the package was created and
+        # information when the package command was not successful. For that reason the output is
+        # always written to the output to help developers diagnose issues.
+        sys.stdout.write(out.decode('utf8').strip())


Also can we write this to Logs instead?

Are logs written to stdout by default during SAM build? I want users to see that information.

normj · 2019-02-26T22:41:19Z

Closing in favor of a new clean branch

* Add support for java21 * fix black formatting * update gha to use java 21 * add missing java 21 testing projects * use gradle-8.4 for java21 --------- Co-authored-by: Mohamed ElAsmar <[email protected]>

normj added 2 commits February 8, 2019 22:07

Start work on .NET Core lambda builder workflow

1c0d215

Add support for passing in command line options

1250ff0

Unzip package zip file Update DESIGN.md

sriram-mv reviewed Feb 12, 2019

View reviewed changes

sanathkr reviewed Feb 14, 2019

View reviewed changes

sriram-mv reviewed Feb 15, 2019

View reviewed changes

Updated docstrings.

c7608ad

sriram-mv mentioned this pull request Feb 20, 2019

added support for powershell lambda functions aws/aws-sam-cli#820

Closed

5 tasks

normj added 2 commits February 21, 2019 12:28

Merge remote-tracking branch 'upstream/develop' into dotnet-build

61b6ce9

Added resolver for the dotnet CLII

d2c04bd

sriram-mv requested changes Feb 21, 2019

View reviewed changes

normj added 13 commits February 22, 2019 12:06

Add .NET Core 2.1.504 to .travis.yml

614818c

Remove trailing : in export PATH

a27c7dc

Add unit tests for .NET Core builder

4425ceb

Add more unit tests

76753bf

Fixed refactor issue with ZipFile

12ff002

Test Cleanup

22f3ca9

Remove extra call to communicate

ac6ab13

Remove unused util methods

63d9c96

Work on Flake issues

2784e64

More flake issues

14230e1

More flake issues

b3615c7

Replace print with sys.stdout.write

7efc34c

Clean up import

8d92e90

sriram-mv reviewed Feb 26, 2019

View reviewed changes

Switch sys.stdout.write to LOG.info

4fac2d8

normj closed this Feb 26, 2019

sanathkr mentioned this pull request Mar 1, 2019

Add support for .NET Core build #91

Merged


		#### Output

		The output of `dotnet lambda package` command is a zip archive that consumers can then deploy to Lambda. For SAM build

Add support for .NET Core build #80

Add support for .NET Core build #80

Uh oh!

Conversation

normj commented Feb 11, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

normj Feb 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sriram-mv left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sriram-mv commented Feb 26, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

normj commented Feb 26, 2019

Uh oh!

Uh oh!

normj Feb 15, 2019 •

edited

Loading