adding web testing projects #120

HongGit · 2018-04-18T00:45:45Z

Add Web testing projects.

HongGit · 2018-04-18T00:47:58Z

Done.

@MichaelSimons this PR contains all test projects. I have verified each DockerFile and made sure that they work properly.

MichaelSimons · 2018-04-19T18:39:34Z

@HongGit - Can you summarize the next steps? I am assuming it is to implement some automation.

richlander · 2018-04-25T04:23:54Z

@HongGit -- you might add a checklist of what you have left to do like I have here: dotnet/dotnet-docker#438

HongGit · 2018-05-04T00:29:29Z

@MichaelSimons and @richlander I am done integrating web testing projects into the main project.

Feel free to let me know if anything is missing.

HongGit · 2018-05-04T00:39:21Z

@MichaelSimons it seems that 4.6.2 Build directory is missing in the build branch, is that by design?

In addition, please let me know once you have 4.7.2 added, I will add the corrsponding web projects as well.

MichaelSimons · 2018-05-10T14:04:29Z

@HongGit - I updated the aspnet-build branch with the latest changes from master. There is no 4.6.2 or 4.7 sdk images. 4.7.2 is the preferred sdk to use to build these projects.

MichaelSimons · 2018-05-10T14:05:45Z

tests/Microsoft.DotNet.Framework.Docker.Tests/ImageTests.cs


+        [Theory]
+        [MemberData(nameof(GetVerifyImagesData))]
+        public void VerifyImagesWithWebApps(ImageDescriptor imageDescriptor)


Seems to be a lot of duplication with the other test case. Consider refactoring to encapsulate the commonality in a single location.

MichaelSimons · 2018-05-10T14:07:20Z

tests/Microsoft.DotNet.Framework.Docker.Tests/projects/webapp-3.5/Dockerfile

+
+RUN msbuild SimpleWebApplication.csproj /verbosity:quiet /p:Configuration=Release
+
+ENTRYPOINT dir ./bin/SimpleWebApplication.dll


The ENTRYPOINT doesn't seem like a real usage scenario. If you want to capture this, it seems like it would be better done with a docker run.

I am trying to make sure that that build was successful. What do you think about using CMD instead?

I think the more canonical way to do this would be do use docker run after you built your Dockerfile - docker run dir ./bin/SimpleWebApplication.dll

I am trying to make sure that that build was successful.

How is this being verified? I'm not seeing any automation that verifies the build was successful other than the Dockerfile built without error. Perhaps that is adequate, I am trying to understand.

The test just verifies that msbuild with no problems. Since no IIS is installed, it's not possible to verify web sites.

I don't see how "docker run" is different from using CMD or ENTRYPOINT. I reverted to my original approach, which is using dir, which verifies right after msbuild.

Please check out my new PR.

I don't see how "docker run" is different from using CMD or ENTRYPOINT. I reverted to my original approach, which is using dir, which verifies right after msbuild.

The responsibility of the Dockerfile in a scenario like this is to build the application. Setting the ENTRYPOINT to list the contents on a directory doesn't make sense and makes the resulting image more difficult to use for anything else as you would need to override the ENTRYPOINT.

Where is the new PR? I am not finding it? Why not just update this PR?

MichaelSimons · 2018-05-10T14:07:49Z

tests/Microsoft.DotNet.Framework.Docker.Tests/projects/webapp-3.5/Dockerfile

+WORKDIR /app
+COPY . ./
+
+RUN msbuild SimpleWebApplication.csproj /verbosity:quiet /p:Configuration=Release


Does the /verbosity:quiet make it difficult to diagnose build failures?

MichaelSimons · 2018-05-16T19:55:55Z

tests/Microsoft.DotNet.Framework.Docker.Tests/projects/webapp-4.6.2/Dockerfile

+
+RUN msbuild SimpleWebApplication.csproj /p:Configuration=Release
+
+RUN dir ./bin/SimpleWebApplication.dll


Per our discussion, I think the verification (e.g. dir ./bin/SimpleWebApplication.dll) logic best belongs in the test case.

I gave this more thoughts. CMD is probably the most appropriate, which is executed during "docker run", that will be the test case you are referring.

I don't understand why it would be most appropriate for the CMD to be dir ./bin/SimpleWebApplication.dll. Please explain. This doesn't seem like a normal usage. I would prefer the Dockerfile to be a typical usage we expect to see. All verification logic should reside within the tests. Please fix so that we can merge this PR.

using CMD, the existence of the dll after build is being verified at docker run time. The verification logic is in the testcase, reside within the tests. Hopefully this answers your questions!

Why is using the CMD most appropriate over using docker run on the resulting image. Per my original comments this is not going to be typical usage. Please change to place the verification logic in the test case.

MichaelSimons · 2018-05-16T19:58:49Z

tests/Microsoft.DotNet.Framework.Docker.Tests/ImageTests.cs

+            {
+                appBuildArgs = new string[]
+                 {
+                        $"BASE_BUILD_IMAGE={baseBuildImage}",


I think it would be best to not have this duplicated. You could change appBuildArgs to a list and initialize it with the build image. The includeRuntime case could then add the runtime image.

This will be addressed in the next PR update.

MichaelSimons · 2018-05-16T19:59:37Z

tests/Microsoft.DotNet.Framework.Docker.Tests/ImageTests.cs

            {
                DockerHelper.DeleteImage(appId);
            }
+


There are a couple WS changes? Were those intentional?

I fixed a merge conflict, is this still an issue?

yes it is. You can see it very easily in the diff.

What is WS? Sorry, I don't see it. All the changes in ImageTests.cs are intentional.

WS is whitespace. Your changes include new blank lines that I don't think add value and make the styling inconsistent.

Got it, it will be removed.

…t-framework-docker into hongaspnet-build

MichaelSimons · 2018-05-22T13:25:18Z

tests/Microsoft.DotNet.Framework.Docker.Tests/DockerHelper.cs

        }

-        public void Build(string tag, string dockerfile, string buildContextPath, params string[] buildArgs)
+        public void Build(string tag, string dockerfile, string buildContextPath, StringCollection buildArgs)


IEnumerable{string} seems more appropriate as there no dependency on StringCollection.

MichaelSimons · 2018-05-22T13:28:54Z

tests/Microsoft.DotNet.Framework.Docker.Tests/ImageTests.cs

        public void VerifyImagesWithWebApps(ImageDescriptor imageDescriptor)
        {
-            VerifyImages(imageDescriptor, "webapp", false);
+            VerifyImages(imageDescriptor, "webapp", $"powershell -command \"dir ./bin/SimpleWebApplication.dll\"", false);


String interpolation is not being used therefore the $ is not necessary.

HongGit · 2018-05-22T18:54:09Z

@MichaelSimons please review the latest update. Will you please merge and approve this PR so we could get this done?

MichaelSimons · 2018-05-22T19:05:32Z

tests/Microsoft.DotNet.Framework.Docker.Tests/DockerHelper.cs

        }

-        public void Build(string tag, string dockerfile, string buildContextPath, StringCollection buildArgs)
+        public void Build(string tag, string dockerfile, string buildContextPath, List<string> buildArgs)


Why the need to take a dependency on List This method just needs to enumerate? IEnumerable{string} allows the caller to pass in a variety of types - arrays, lists, collection, etc..

There was not an easy way to add to IEnumerable , that is why I used List here.

What is wrong with

public void Build(string tag, string dockerfile, string buildContextPath, IEnumerable<string> buildArgs)

There is nothing wrong with that. What I need here is to initialize this collection with one string, and in some situation, Add another string to it. I did not see that IEnumerable supports Add method.

List<string> implements IEnumerable<string> so you will be able to pass in a List<string> type into a method that has an IEnumerable<string> parameter.

MichaelSimons · 2018-05-22T22:02:52Z

tests/Microsoft.DotNet.Framework.Docker.Tests/DockerHelper.cs

            if (buildArgs != null)
            {
-                foreach (string arg in buildArgs)
+                foreach (Object arg in buildArgs)


This change should be reverted with your change to use IEnumerable<string>

adding web testing projects

ae96f9e

integrate web projects into ImageTests.cs

18d07e5

MichaelSimons reviewed May 10, 2018

View reviewed changes

update per feedback

d7fb3bf

MichaelSimons reviewed May 16, 2018

View reviewed changes

HongGit added 3 commits May 16, 2018 18:43

Merge branch 'aspnet-build' into hongaspnet-build

9f75eba

second update per code review feedbacks

87386d4

Merge branch 'hongaspnet-build' of https://github.com/Microsoft/dotne…

dc15a0a

…t-framework-docker into hongaspnet-build

MichaelSimons reviewed May 22, 2018

View reviewed changes

3rd update per code review feedbacks

2249368

MichaelSimons reviewed May 22, 2018

View reviewed changes

HongGit added 2 commits May 22, 2018 14:59

4th update per code review feedback

5d3aef5

hopefully last update for this PR

ad2988e

MichaelSimons reviewed May 22, 2018

View reviewed changes

MichaelSimons merged commit 226ae0c into aspnet-build May 22, 2018

MichaelSimons deleted the hongaspnet-build branch May 22, 2018 22:16


		RUN msbuild SimpleWebApplication.csproj /verbosity:quiet /p:Configuration=Release

		ENTRYPOINT dir ./bin/SimpleWebApplication.dll


		RUN msbuild SimpleWebApplication.csproj /p:Configuration=Release

		RUN dir ./bin/SimpleWebApplication.dll No newline at end of file

adding web testing projects #120

adding web testing projects #120

Uh oh!

Conversation

HongGit commented Apr 18, 2018

Uh oh!

HongGit commented Apr 18, 2018

Uh oh!

MichaelSimons commented Apr 19, 2018

Uh oh!

richlander commented Apr 25, 2018

Uh oh!

HongGit commented May 4, 2018

Uh oh!

HongGit commented May 4, 2018

Uh oh!

MichaelSimons commented May 10, 2018

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!

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!

MichaelSimons May 22, 2018 • 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!

HongGit commented May 22, 2018

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!

MichaelSimons May 22, 2018 •

edited

Loading