Add .webappignore and .funcignore Support for Service Packaging
#4258
Conversation
jongio
requested review from
ellismg,
wbreza,
vhvb1989,
hemarina and
weikanglim
as code owners
|
This seems helpful, per discussions on the other PR! My main design question would be why a separate file versus an --ignore in the azure.yaml. Is it easier to define globs that way? Does YAML have annoying syntax restrictions? |
One of the reasons was for making this new ignore-file recognizable beyond azd; so you could use it when using web-app-deploy action (https://github.com/Azure/webapps-deploy) or your own tools. @jongio was going to check with App Service if there was something already for it and if not, it might be worth it to have it beyond azd; similar to .dockerignore, .npmignore, etc. Then azd would just honor this file like any other tool would. |
Yes, I'm in talks with them on this. |
|
Ah, cool, that design makes sense then! |
|
Comment from @Petermarcu
@ellismg - You first suggested .zipdeployignore, we landed on .zipignore because it's not necessarily part of the deploy action, instead it is part of packaging. We want the file name to be generic enough to be used by other app service related tooling. In the same vein as .funcignore, .dockerignore, should we name this .webappignore? |
|
Is this only going to be respected for app service services? |
Yes, most of the other services already have .*ignore files, .funcignore, .dockerignore |
|
Related: #4215 |
@ellismg - I've confirmed with the web app and functions teams that they would prefer |
jongio
changed the title
.zipignore Support for Service Packaging.webappignore and .funcignore Support for Service Packaging
| func GetIgnoreFileNameByKind(kind ServiceTargetKind) string { | ||
| switch kind { | ||
| case AzureFunctionTarget: | ||
| return ".funcignore" | ||
| case AppServiceTarget: | ||
| return ".webappignore" | ||
| default: | ||
| return "" | ||
| } | ||
| } |
There was a problem hiding this comment.
I debated on whether or not we should have a helper method like this, or add this to the interface, but since only a few of the service targets will have this capability I figured we should add it as a helper method to not mess with the interface of the service target. But I could be convinced the other direction, depending on how you want to design this.
There was a problem hiding this comment.
I like flexibility -- simple functions are great for that purpose. I'm okay here.
|
@wbreza @vhvb1989 @ellismg - Could you have a look at the updated code and PR description with all the changes? I'm in discussion with the appservice team and the approach with .webappignore and .funcignore are aligned with them. @pamelafox - Once we get a build could you verify this works as expected in your projects with and without .webappignore files? (You'll obviously need to create the .webappignore file in the project this impacts) @v-xuto - Can you please run manual regression / smoke tests on all the azdev ToDo templates and ensure that everything passes? Thanks! |
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Do you also want to run the azdev ToDo templates through the validation pipeline with this change? cc @anfibiacreativa |
Got it. Testing. |
| ignoreFileName := GetIgnoreFileNameByKind(serviceConfig.Host) | ||
|
|
||
| // Read and honor the specified ignore file if it exists | ||
| ignoreMatcher, err := dotignore.ReadDotIgnoreFile(src, ignoreFileName) |
There was a problem hiding this comment.
Are we also thinking about supporting *.ignore files in any recursive child directory of the service?
- funcapp/
- .funcignore
- src/
- otherThing/
- .funcignore # define ignore files relative to this path
In my mind, I think azd would honor both ignore files.
If we're doing this, I think we should consider implementing the correct recursion logic in project before generalizing it as a dotignore package -- I would like to see the design matured out before we push it up to an app library package in azd.
There was a problem hiding this comment.
@ellismg had implemented .dockerignore recently -- wonder if he has thoughts here.
There was a problem hiding this comment.
.funcignore only honors files in the root and in discussion with them and the app service team we decided to not honor recursive .ignore files.
There was a problem hiding this comment.
.funcignore only honors files in the root and in discussion with them and the app service team we decided to not honor recursive .ignore files.
That is quite an interesting decision. From a dev perspective, one main reason why *.ignore files are used today is precisely because they can always be placed relative to a directory and provide a more local ignore scope. If that is not being done, a simpler package manifest at the root of the package directory would be a more ideal format IMO.
I took a closer look. It also turns out that .funcignore does not conform to the .gitignore spec entirely. @ellismg @jongio
- The issue on functools
- Based on the previous issue, I gather that the library they're using is gitignore-parser with its set of issues.
If we're already engaged in conversations with both app service and function teams, can we consider:
- Evaluating the impact of having two different
.funcignoreinterpretations (is there user pain we would worry about?) - Based on those conversations, decide if we would like to rally all teams to adopt the conformant spec, and think about potentially support recursive directories. We could also just support recursive directories from
azdside for now, it would be perhaps 20 lines of code, and something users would care about -- perhaps not today immediately, but some day in the near future.
| os.Remove(zipFile.Name()) | ||
| return "", err | ||
| } | ||
|
|
||
| return zipFile.Name(), nil | ||
| return filePath, nil |
There was a problem hiding this comment.
I'm assuming filePath gives us the full absolute path while zipFile.Name() was only giving us the filename? I would just double check that this is honored downstream of the caller.
Description:
This PR introduces support for
.webappignoreand.funcignorefiles to the service packaging process within the Azure Developer CLI (azd). These files allow users to specify files and directories that should be excluded from the deployment package for App Service and Function Apps, providing fine-grained control at the service level.Key Updates:
.webappignoreand.funcignoreFile Support:.webappignorefor App Services and.funcignorefor Azure Functions within individual service directories..webappignoreor.funcignorefile exists in a service directory, the packaging process will follow its rules, allowing granular control over which files are included or excluded in the service's zip archive.Updated Exclusion Logic:
__pycache__,.venv, andnode_modulesunless a.webappignoreor.funcignorefile is present, which can override these default exclusions..webappignorefile is present in an App Service, directories such asnode_modulesor__pycache__can be included or excluded as specified..funcignorecan similarly be used to specify inclusion/exclusion rules..webappignoreor.funcignorefile is present, default exclusions apply for Python (__pycache__,.venv) and Node.js (node_modules).Test Coverage:
.webappignoreand.funcignorefiles.__pycache__,.venv, andnode_modulesbased on the presence or absence of the ignore files..webappignoreand.funcignorebehavior is correctly respected.logs/log.txtcan be excluded based on the ignore file configuration.Sample Project Structure:
.webappignorefiles explicitly include or excludenode_modulesor__pycache__based on real-world usage patterns.Documentation:
.webappignoreand.funcignorefiles with examples for both Python and Node.js projects.Testing:
All test cases have been successfully executed, covering a broad range of scenarios to ensure expected packaging behavior. The tests ensure that both
.webappignoreand.funcignorefiles are respected and that default exclusions are correctly applied when no ignore file is present.Additional Notes:
.webappignoreor.funcignorefiles into their services.How to Review:
.webappignoreand.funcignorefiles influence the exclusion logic.