Add Dockerfile port detection to ingress configuration logic#449
Add Dockerfile port detection to ingress configuration logic#449MicroFish91 merged 29 commits intomainfrom
Dockerfile port detection to ingress configuration logic#449Conversation
…inerapps into mwf/deployWorkspaceProject-I
1da4d49 to
57e86fe
Compare
| context.targetPort = getDefaultPort(context); | ||
| } | ||
|
|
||
| // If a container app already exists, activity children will be added automatically in later execute steps |
There was a problem hiding this comment.
Will add this back in once we add all the activity children support in upcoming PR
|
|
||
| const portRanges: PortRange[] = []; | ||
| for (const line of lines) { | ||
| if (/^EXPOSE/i.test(line.trim())) { |
There was a problem hiding this comment.
Dockerfiles aren't too tough to parse, but it may be easier to use an existing parser. The Dockerfile language service used by the Docker extension has one. https://www.npmjs.com/package/dockerfile-ast
There was a problem hiding this comment.
Hmm, I did look into this one a little bit before and I ended up feeling unsure if it removed enough complexity to warrant adding a third party dependency since the scope of use is relatively small here.
From what I can tell, I would still have to loop through each line in search of an expose keyword (fairly similar to what I'm doing already). Also the parsed args list it provides is still made up of raw strings that I have to loop through again to identify ranges - and slashes / so that I can convert them into useable port numbers/ranges.
I think the main benefit I see is that it might reduce the complexity of some of the RegExp that I'm using, but the overall process doesn't seem to get that much simpler. With this context, do you think it would still be beneficial to use the new dep?
There was a problem hiding this comment.
That's fair, I think it's fine to manually parse, just make sure you know all the variations that an EXPOSE statement can have.
6786c9c to
a721f97
Compare
…crosoft/vscode-azurecontainerapps into mwf/deployWorkspaceProject-III
| } | ||
| } | ||
|
|
||
| export async function getDockerfileExposePorts(dockerfilePath: string): Promise<PortRange[] | undefined> { |
There was a problem hiding this comment.
Should call this tryGetDockerfileExposePorts since it can return undefined.
There was a problem hiding this comment.
Also feels like that this should just be in its own file.
| @@ -0,0 +1,7 @@ | |||
| ## Modified example from Azure-Samples/acr-build-helloworld-node | |||
| FROM node:15-alpine | |||
There was a problem hiding this comment.
I assume that it probably doesn't matter for our unit tests, but should we try to target things other than node:15-alpine?
There was a problem hiding this comment.
That's fair, I literally just copy pasted everything from the original azure-sample and just changed the expose sections
|
|
||
| import type { PortRange } from "../../extension.bundle"; | ||
|
|
||
| export interface MockIngressContext { |
There was a problem hiding this comment.
Just want to confirm, but the reason you're not just using the IngressContext because of the containerApp has too many required properties that aren't worth mocking?
There was a problem hiding this comment.
Yeah, that's a big part of the reason
| for (const [i, ds] of dockerfileSamples.entries()) { | ||
| const context: MockIngressContext = { | ||
| dockerfilePath: i === 1 ? undefined : ds.fsPath, | ||
| alwaysPromptIngress: i === 3 |
There was a problem hiding this comment.
I assume that you're only setting this true for the 4th dockerfile? Maybe add a comment in the expected results which one has this true?
I'm not sure how to do it better, but I think it would be kind of difficult to add tests to this suite if we ever do. Definitely not worth blocking, but I'll keep thinking about it as well.
There was a problem hiding this comment.
I have it in the expected results array at the top!
There was a problem hiding this comment.
I'll add the =true modifier
|
|
||
| context.dockerfileExposePorts = await getDockerfileExposePorts(context.dockerfilePath); | ||
|
|
||
| if (context.alwaysPromptIngress) { |
There was a problem hiding this comment.
Small nit, but should probably be at the top of the file so we don't waste any time doing the async call above.
There was a problem hiding this comment.
This position is intentional, because it's still nice to grab the expose ports so we can provide port suggestions later down the line (results can be leveraged when we call getDefaultPort again later)
6ca6925 to
de11fc0
Compare
Related to: #425
Added a pre-configuration path for ingress when a Dockerfile is detected + tests