Deploy using RFP when azure files connection string not set

[ColbyTresness]

"If the azure files connection string is not set, VS code deploys loose files"

[ejizba]

@paulbatum what do you mean by "loose files"? What's the action item here?

[ColbyTresness]

By loose files we mean zip deploy without run from package (resulting in a zip file being uploaded, then unzipped, yielding loose files). The action item is to still deploy using Run From Package when the azure files connection string isn't set

[paulbatum]

Seems like this issue is missing some important context... this came out of my linux elastic premium investigation. By loose files, I just mean its not a package deployment.

In the case of using VS code to deploy to a linux elastic premium app that does not correctly have the azure files connection string set, I noticed that it was not doing a run from package deployment. I thought that VS code was supposed to default to run from package deployments.

[ejizba]

When you say "Run from package deployment" are you talking about explicitly setting WEBSITE_RUN_FROM_PACKAGE to a blob url? We only did that on Linux consumption as a workaround because it didn't support the "zipdeploy" kudu/oryx endpoint yet. We always expected linux deploy to work the same as Windows in the sense that we push files to the zipdeploy endpoint and "Run from package" is turned on or off by setting WEBSITE_RUN_FROM_PACKAGE to '1'

[paulbatum]

Trying to understand the contract here... if I ignore any create flows for a second, and just focus on how VS code handles existing apps, would it be correct to say that VS code does not currently set WEBSITE_RUN_FROM_PACKAGE=1 during any type of deployment?

[ejizba]

Yes that is correct

[paulbatum]

Okay, that clears up a misunderstanding on my part. I think I need to talk with some more folks on my team to see if we want to ask you to change that. If the answer is no, then there is no work to do for this issue and it should be closed. I'll follow up.

[ColbyTresness]

Sorry, but how is that true? Didn't we switch the default to use run from package across all scenarios?

The implementation would be different on linux consumption, since it requires setting the SAS URL, but I could have sworn that we changed this a while back.

Perhaps that was a big misunderstanding about what constitutes "Run from package" - now that I'm thinking about it I've never tested it explicitly, just trusted that @fiveisprime said we now use run from package by default. But if he meant only for linux consumption then we weren't on the same page.

If you're not setting the run from package app setting to '1' at all now, we definitely do want you to change that, since it's the best way to run function apps. I just didn't realize that wasn't the case until now.

[ejizba]

@ColbyTresness he said "if I ignore any create flows". For create, we do set WEBSITE_RUN_FROM_PACKAGE to 1 on all Windows apps

[ColbyTresness]

Ok this makes way more sense. Sorry for the confusion

[ejizba]

@paulbatum any update here? Specifically - what's the recommendation between these two methods of deploying to linux premium:

1. Set WEBSITE_RUN_FROM_PACKAGE to 1 and upload zip file using zipdeploy endpoint
2. Upload zip file to storage account and set WEBSITE_RUN_FROM_PACKAGE to sas url

We would much prefer option 1, to be consistent with Windows and simplify our deploy logic. As mentioned above, option 2 was always messaged as a workaround to us until the zipdeploy endpoint was fully supported on linux

[paulbatum]

Thanks for the ping. I'm not suggesting that you switch linux premium flows to upload to storage. The answer to your question is we recommend the first approach.

But I think the thing that is missing right now is setting WEBSITE_RUN_FROM_PACKAGE to 1 at deployment time. Right now VS code only sets it at create time. If you create the function app through the portal and then deploy from VS code you miss out on the benefits of run-from-package.

If VS code was updated to set this value at deployment time, would that also resolve the problem discussed in #1684?