WEBSITE_CONTENTSHARE should not be used accroding to support

Hi there,
I raised support case<PHONE_NUMBER>00245, where the support engineer advised that WEBSITE_CONTENTSHARE should not be set at all in ARM deployments, as it should be managed by the function runtime. Not setting it seems to avoid an issue where an unintentional swap may occur during a redeployment. (see case information for details)
If this is the official guidance, should we add a note on this page to let people know?
Also, should WEBSITE_CONTENTSHARE be excluded when exporting AppService templates? (via Portal or PowerShell)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 18aa54fd-3aa1-37c5-925c-51a0195b1030
Version Independent ID: 60198016-1ea9-e7ae-b00b-2c665d5ad8ca
Content: App settings reference for Azure Functions
Content Source: articles/azure-functions/functions-app-settings.md
Service: azure-functions
GitHub Login: @ggailey777
Microsoft Alias: glenga

@danielstocker Thank you so much for bringing this to our attention. I have this assigned to the service lead to be investigated further and will make an update when we have greater clarity.

@Mike-Ubezzi-MSFT @mike-urnun-msft
Thanks for looking into this.
Do you need any more information to progress this?

@danielstocker can you provide more background about what was your original issue which leads to this discovery? I am not sure to properly understand the implication to set it improperly (what you mentioned as an unintentional swap)

Hi @ggirard07,
No problem. Let me summarise.
This came up initially because our documentation states that WEBSITE_CONTENTSHARE is required. (see here: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#windows)
If we export a Functions template from the Marketplace (export template on the last page) we get WEBSITE_CONTENTSHARE as a standard app setting. If we use this, then the following situation can happen.

We deploy an ARM template and get an empty function with two slots
We deploy to the staging slot
We swap to make the content available in production
UNINTENDED SWAP as the ARM template is redeployed and app settings are reapplied (this even happens during an incremental ARM deployment as the appsettings resource always overwrites and resets the WEBSITE_CONTENTSHARE setting)
Deployment routine now deploys the new code to the staging slot and our production slot is empty rather than containing the previous version. Our production function is "unintentionally" down

The customer in this particular case then pointed to this article https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
This suggests that the setting should be set as a slot setting to fix the behaviour. While this does fix the behaviour in my tests, it seems wrong, because it should not work.
Below is a table of what happened in my tests. (after making it a slot setting)

My (and the customer's) perception is that the slots should not swap at all anymore, but as described in the article, it still works anyway.
I raised this internally as well and people found inconsistent behaviour when changing app settings. (Hence why this is highlighted in my testing grid) For a colleague testing it, updating the app settings, made the slot settings re-apply thus again causing an unintended swap.
This then finally (sorry about the lengthy response) led me to raise the support case where the outcome was "just do not set the setting at all".
My personal tests showed that this does fix the issue, but there is no guidance in the documentation to confirm this, hence why I raised this item.
Hope this helps.
Let me know if anything is unclear.

@danielstocker definitively an important information, especially to understand how the slots and swapping are working for Functions vs a traditional webapp with webjobs.
Also this is not explained either in the slots documentation despite 'WEBSITE_CONTENTSHARE' playing a critical role here. There is only a single screenshot at step 4 representing it, where those values are truncated to make things even more clear...

Hi @ggirard07 and thanks for reading through my diatribe. So what's the way forward from here? :)

@ggirard07 @ggailey777 @mike-urnun-msft
Is more information required to create some documentation clarity around this behaviour? I'm working with a customer who is considering stopping to use function slots because they are unsure about the official guidance around this scenario.
Thanks for your help

@danielstocker Just so that I am clear on what you think will address the documentation issues related to this:

Remove the WEBSITE_CONTENTSHARE deployment setting from here.
Add a note in the reference article that WEBSITE_CONTENTSHARE should only be set by the runtime.

Do you think that would be sufficient?
cc. @mattchenderson

Hi @ggailey777
Yes I think that'd be a good solution

Isn't WEBSITE_CONTENTSHARE one of the required appsetting when deploying a function App using ARM?

Isn't WEBSITE_CONTENTSHARE one of the required appsetting when deploying a function App using ARM?

If it isn't applied then the runtime will generate one for you, i think.

I deployed an ARM with a Consumption-plan and a Function App with a section Microsoft.Web/sites/config named appsettings and the following properties

FUNCTIONS_EXTENSION_VERSION : "~2",
FUNCTIONS_WORKER_RUNTIME : "dotnet",
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING : [storage connectionstring]
WEBSITE_NODE_DEFAULT_VERSION: 6.5.0

The deployment returned the following error:
      "ErrorEntity": {
        "ExtendedCode": "01010",
        "MessageTemplate": "Required parameter {0} is missing.",
        "Parameters": [
          "WEBSITE_CONTENTSHARE"
        ],
        "Code": "BadRequest",
        "Message": "Required parameter WEBSITE_CONTENTSHARE is missing."

After I also removed parameter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, the deployment went succeeded.
It looks like WEBSITE_CONTENTSHARE can only be removed together with parameter WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.

We have been seeing the exact behavior @tjgalama has described and are also wondering where the file shares with the function packages are stored.
Our function apps also include a timer triggered function, so we specify the AzureWebJobsStorage setting as suggested: we would have guessed/hoped the runtime would have used that same connection string for the (now implicit) WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, but that isn't the case: in the storage account we specify there, we do see the azure-webjobs-hosts and azure-webjobs-secrets blob containers, but no file shares are present.
I have checked in Kudu for clues and it looks like all the files that needs to be there are in the file system (wherever that is, checked on app-name.scm.azurewebsites.net/api/vfs/), but no reference to either settings (WEBSITE_CONTENTSHARE or WEBSITE_CONTENTAZUREFILECONNECTIONSTRING) is to be seen in the environment tab (appname.scm.azurewebsites.net/Env.cshtml).
Maybe important to mention, our apps are set up with WEBSITE_ENABLE_SYNC_UPDATE_SITE=True and WEBSITE_RUN_FROM_PACKAGE=1.
The apps seem to work, but we would really like some clarity on this point, as we are porting a core business service to Azure Functions and want to figure this one out before rolling out to production.

Following some advice, we had set WEBSITE_CONTENTSHARE as a slot setting to make sure the values were distinct between our production and staging slots. Today, the ARM template that we use started failing with 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (even though I confirmed that it is indeed set as a slot setting in the portal currently). Did something around this behavior change?

We have noticed this same issue over the past few days and need guidance on how to proceed.  We have also been following the approach of setting the WEBSITE_CONTENTSHARE as a slot setting to get around the unintentional swap issue but now can't deploy due to this error.  I have tried retroactively removing both this and the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING settings to move towards what appears to be the recommended approach of not using either, but these deployments would also fail.

Following some advice, we had set WEBSITE_CONTENTSHARE as a slot setting to make sure the values were distinct between our production and staging slots. Today, the ARM template that we use started failing with 'WEBSITE_CONTENTSHARE' cannot be a slot setting. (even though I confirmed that it is indeed set as a slot setting in the portal currently). Did something around this behavior change?

Remove it and let the runtime pick a name. Thid is how I do it.

@jeffhollan can you give us some clarity please
This says that WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING are required: https://docs.microsoft.com/en-us/azure/azure-functions/functions-infrastructure-as-code#create-a-function-app
Commenters here think they are not required; ARM thinks they are required?; Azure support thinks that WEBSITE_CONTENTSHARE breaks slot scenarios.

We ended up checking the code of the Azure functions host and it looks like, when running from package, the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING setting is not used.
We verified it by removing from our ARM template both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE and obtaining good results: our function apps don't have those two settings at all (not even assigned by the runtime) and they don't use file shares in any storage account (at least that we can see).

So one thing to keep in mind is that the filesystem for a webapp/function app looks something like this:
home
|-data
|-LogFiles
|-site
  |-deployments
  |-tools
  |-wwwroot

When you use run from package, that only replaces the wwwroot folder in this tree. Everything else is provided by the main file system. If you make a consumption or elastic premium function app without WEBSITE_CONTENTAZUREFILECONNECTIONSTRING then the main filesystem is not available outside of the scale unit the function app was created in. This is not a supported/recommended configuration. It means that your function app may not scale beyond the limits of the scale unit it was created in, or if it does, you won't be able to trust that the filesystem state outside of wwwroot stays consistent.
The most recent guidance I've seen from the dev that owns how WEBSITE_CONTENTSHARE interacts with slots is the following:

WEBSITE_CONTENTSHARE should NOT be a slot setting. An API change that blocks this is rolling out at time of writing.
At initial creation of the resource via ARM, WEBSITE_CONTENTSHARE should be set. However after initial creation, this setting should be omitted from the ARM template (because if it was included, further executions of the ARM template might cause unexpected content swaps)

Following from my comment above.. I also discovered that the system currently has some inconsistent behavior regarding generating WEBSITE_CONTENTSHARE so that you don't even need to specify it initially. Some of you have been saying that you haven't needed to specify it, while others are getting an error saying its required. As far as I can tell, this behavior works correctly for consumption (i.e. an ARM template for consumption does not need this setting initally) but the same is not true for elastic premium. That behavior is getting fixed, but it will probably take 1-2 months to make its way out. So in the meantime, the guidance I shared above (where you set it initially and then remove it from the ARM template) is applicable.

@paulbatum

At initial creation of the resource via ARM, WEBSITE_CONTENTSHARE should be set. However after initial creation, this setting should be omitted from the ARM template (because if it was included, further executions of the ARM template might cause unexpected content swaps)

You do realize this kind of break the purpose of an ARM template, right?

That behavior is getting fixed, but it will probably take 1-2 months to make its way out. So in the meantime, the guidance I shared above (where you set it initially and then remove it from the ARM template) is applicable.

What is the final expected configuration here?
Can we get an announcement on Azure/app-service-announcements with proper configuration and official timeline once all this is actually deployed?

This is what I get for trying to be helpful. Yes I know how ARM templates are supposed to work :/

Hi, not sure if there's been any development on this. I am still struggling to use ARM templates with WEBSITE_CONTENTSHARE flag. @paulbatum how can I omit a configuration from the ARM template? I had to completely disable the step in order to get it working, but as @ggirard07 said I think that also defeats the purpose of the ARM template.

@gustavobmichel Sorry, I dont understand your question. The ARM template is JSON, you edit it as required. It appears as part of the appsettings section, e.g:
          "appSettings": [
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';EndpointSuffix=', environment().suffixes.storage, ';AccountKey=',listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },

Hi @paulbatum, thanks for coming back to me. I thought you mentioned about programatically omitting the settings from JSON template, so that was my question.
As others stated I also thought these two settings were required, so I removed the two from my ARM template.
To test this feature with zero-downtime I created a simple test with the bare mininum infrastructure to test it. I removed all the resources from my resource group and ran the ARM template as part of the release pipeline to create the resources without WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE and WEBSITE_RUN_FROM_PACKAGE.
I ran a couple of tests and it is still all working ok using the consumption plan. I'll do some tests this week with the premium tier.
I have also added this configuration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to 1 as per this link: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot-swaps
I have attached my test ARM template for reference.
azuredeploy.txt

Hi @paulbatum, thanks for coming back to me. I thought you mentioned about programatically omitting the settings from JSON template, so that was my question.
As others stated I also thought these two settings were required, so I removed the two from my ARM template.
To test this feature with zero-downtime I created a simple test with the bare mininum infrastructure to test it. I removed all the resources from my resource group and ran the ARM template as part of the release pipeline to create the resources without WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE and WEBSITE_RUN_FROM_PACKAGE.
I ran a couple of tests and it is still all working ok using the consumption plan. I'll do some tests this week with the premium tier.
I have also added this configuration WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to 1 as per this link: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#troubleshoot-swaps
I have attached my test ARM template for reference.
azuredeploy.txt

Leaving out WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, how does your function know where to get the app code from?

If it helps, we have settled on:

setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING to the storage account we want the code running from
not specifying WEBSITE_CONTENTSHARE at all in the arm template (allow it to be auto generated for both slots)
WEBSITE_RUN_FROM_PACKAGE = 1

I did a lot of testing around these and this seemed like the best configuration to avoid triggering unintentional swaps and knowing where the code was sitting, etc.  Also doesn't require managing these settings outside of the ARM template, which I didn't like the idea of (feels like there's not a lot of point to using ARM templates at that point).
The deployment does also seem to work without specifying a WEBSITE_CONTENTAZUREFILECONNECTIONSTRING value at all, but as mentioned we couldn't find out where the code was sitting and the MS support guy handling my ticket seemed to suggest this was a bug and shouldn't be allowed by the platform.

If it helps, we have settled on:

setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING to the storage account we want the code running from
not specifying WEBSITE_CONTENTSHARE at all in the arm template (allow it to be auto generated for both slots)
WEBSITE_RUN_FROM_PACKAGE = 1

I did a lot of testing around these and this seemed like the best configuration to avoid triggering unintentional swaps and knowing where the code was sitting, etc. Also doesn't require managing these settings outside of the ARM template, which I didn't like the idea of (feels like there's not a lot of point to using ARM templates at that point).
The deployment does also seem to work without specifying a WEBSITE_CONTENTAZUREFILECONNECTIONSTRING value at all, but as mentioned we couldn't find out where the code was sitting and the MS support guy handling my ticket seemed to suggest this was a bug and shouldn't be allowed by the platform.

This is exactly what I have found out as well. Thanks for confirming.

I am having issues with accessing the storage after adding WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_RUN_FROM_PACKAGE. Did you guys add these two configs to both functionapp and slot?

My function is having issues with accessing the storage after adding WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_RUN_FROM_PACKAGE. Did you guys add these two configs to both functionapp and slot?
The exact error is: Azure Functions Runtime is unreachable.
That is after I do the first deployment and then I attempt to deploy a new version.
I added my yml file as well.
yml file.txt
deploy.txt
I also updated my ARM template.

I have it on both. Actually I have nothing in my production slot and swap everything in from staging. I have seen this when defining a WEBSITE_CONTENTSHARE or not pointing to the correct storage account where code reside with WEBSITE_CONTENTAZUREFILECONNECTIONSTRING. You need to not point anything anywhere with WEBSITE_CONTENTSHARE. I actually think I saw that error you refer to becsuse of adding a WEBSITE_CONTENTSHARE to environment variables. Make sure you don't have it defined.

Hi @mslot, I think the problem was on my deployment. I was setting it to zipDeploy because I read on this thread https://stackoverflow.com/a/56205917 about setting it on Azure DevOps. After I changed it to standard deployment, everything seems to be working. Thanks for your help.

Hi @mslot, I think the problem was on my deployment. I was setting it to zipDeploy because I read on this thread https://stackoverflow.com/a/56205917 about setting it on Azure DevOps. After I changed it to standard deployment, everything seems to be working. Thanks for your help.

That correct. Actually you could set it to zip deploy again and remove the RUN_FROM_PACKAGE then I think it should work.

That behavior is getting fixed, but it will probably take 1-2 months to make its way out.

Any update on this issue? Is the Consumption and Premium behavior now aligned? Can we omit WEBSITE_CONTENTSHARE from the initial ARM deployment and subsequent deployments? How does this affect staging slots? Any updated docs to link to or guidance?
We have essentially settled on the same approach as @thomaswilkin and @mslot but just through experimentation and trial-and-error. Still not even sure how the runtime knows where to find our files since WEBSITE_CONTENTSHARE is not set.

Hi. Not sure how can you guys do ti but it seems like I can't deploy with
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING without WEBSITE_CONTENTSHARE. Even through the portal, it gave me an error while trying to set the config;
Failed to update web app settings: Required parameter WEBSITE_CONTENTSHARE is missing.
On the overview page of the function app I also see this warning message: Storage is not configured, Function scaling will be limited. Click to learn more. I'm running on a premium plan. Any updates or official guideline on how should we config our function apps?

For the Premium plan (not 100% sure about Consumption plan), here is the matrix of what works/doesn't work:

if you deploy a new resource:

if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it fails with Required parameter WEBSITE_CONTENTSHARE is missing
if you supply both values, it works

if you deploy to an existing resource

if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it succeeds (and appears to work fine afterwards) even though WEBSITE_CONTENTSHARE is supposed to be required
if you supply both values, it 'works' in that the ARM part does not fail, but it causes the multiple-restart issue and the MS guidance above is to not set WEBSITE_CONTENTSHARE on the updates

So there does not appear to be a way to have a single ARM template that works for both scenarios at the moment.

I also see this warning message: Storage is not configured, Function scaling will be limited. Click to learn more . Havent had website WEBSITE_CONTENTAZUREFILECONNECTIONSTRING or WEBSITE_CONTENTSHARE. Just as Korkiak mention, any updated or official guideline?

We've recently started seeing the message "Storage is not configured, Function scaling will be limited. Click to learn more" in the Azure Portal for existing Azure Functions that were deployed four weeks ago.

We've recently started seeing the message "Storage is not configured, Function scaling will be limited. Click to learn more" in the Azure Portal for existing Azure Functions that were deployed four weeks ago. We have never used WEBSITE_CONTENTAZUREFILECONNECTIONSTRING nor WEBSITE_CONTENTSHARE.

@paulbatum Seems like this issue is getting more activity over the last few days since the 'Storage is not configured, Function scaling will be limited' message started showing up in the portal. Any new guidance on the correct way to configure all of this?

I have just encounted the 'WEBSITE_CONTENTSHARE' cannot be a slot setting error as mention above when deploying a new Function App for the first time in serveral months using a template that has worked fine before.
The template has 'WEBSITE_CONTENTSHARE' as a slot setting and defined in both the Function App and deployment slot appsettings as per the following article that has also be mention above:
https://nascent.blog/2017/06/27/azure-functions-slots-arm-templates-snags-2-redeploy-causes-unwanted-swap/
Reading this thread removed this as a slot setting and tried various combinations of setting 'WEBSITE_CONTENTSHARE' and I'm not getting the same behaviour as others.  I can can deploy with no errors as below:

Specify 'WEBSITE_CONTENTSHARE' for both Function App & Deployment Slot
Specify 'WEBSITE_CONTENTSHARE' for Function App only

If I do not specifiy 'WEBSITE_CONTENTSHARE' at all in the template I get the "Required parameter WEBSITE_CONTENTSHARE is missing" error.
So please can we have an update on what the actual settings should be as I can't deploy to production with this current behaviour.

Hey everyone, sorry for all the confusion here.  We were trying to be smart by having the Azure Portal tell you when you may run into scaling issues with your configuration, but we goofed up the logic and so now people may be seeing the warning incorrectly. We're working on a fix but in the meantime here's how to validate if you may run into scaling issues with your app or not:
If you're running on elastic premium or consumption, then you must meet one of the following criteria:

You must have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined

or

If you're using run from zip/package, then you must have "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP", or "WEBSITE_RUN_FROM_PACKAGE" set to something other than empty, 0, or 1

Thanks @ehamai - for # 2 when you say 'set to something other than empty, 0, or 1' - is that correct? arent 0 and 1 opposites? (We have ours set to 1 and we assumed that meant yes/true (do run from package) as documented here: https://docs.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package)

Hi Elliott, many thanks for the extremely swift reply.
So just to clarify:
When deploying from an ARM template to the Consumption plan and using a deployment slot but No zip/package

     I should define both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE on both the Production and Staging slot.

     I should NOT define WEBSITE_CONTENTSHARE as a deployment slot setting on either slot.

Best regards
Owain
From: Elliott Hamai<EMAIL_ADDRESS>Sent: 22 June 2020 17:31
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Owain Winterbone (ITCS - Staff<EMAIL_ADDRESS>Manual<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE should not be used accroding to support (#36458)
Warning: This email is from outside the UEA system. Do not click on links or attachments unless you expect them from the sender and know the content is safe.
Hey everyone, sorry for all the confusion here. We were trying to be smart by having the Azure Portal tell you when you may run into scaling issues with your configuration, but we goofed up the logic and so now people may be seeing the warning incorrectly. We're working on a fix but in the meantime here's how to validate if you may run into scaling issues with your app or not:
If you're running on elastic premium or consumption, then you must meet one of the following criteria:

You must have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined

or

If you're using run from zip/package, then you must have "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP", or "WEBSITE_RUN_FROM_PACKAGE" set to something other than empty, 0, or 1

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647631943&data=02|01|o.winterbone%40uea.ac.uk|ecd3322262374fb9ffb608d816c9ad12|c65f8795ba3d43518a070865e5d8f090|0|0|637284402737046987&sdata=woJvSwWrHgKQIV3xQ8QX3vIOULv6ZNfn5wln4tPn3EA%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PC23VOJOEKS6ESN2C3RX6BM5ANCNFSM4IJGDPBQ&data=02|01|o.winterbone%40uea.ac.uk|ecd3322262374fb9ffb608d816c9ad12|c65f8795ba3d43518a070865e5d8f090|0|0|637284402737056941&sdata=StHshC6EtV6A%2BLi3g7x0xfNx56POAYnwjMWihEf%2BCYM%3D&reserved=0.

@briandunnington - Yeah sorry it's confusing.

0 means disabled
1 means run from a local zip but for that to work properly, you need to also have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined by the first statement.

@OwainWin - Sorry I'm confused by your question.  You asked if you should and should not include WEBSITE_CONTENTSHARE.
I believe you should have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined on both the production and staging slot.

Thanks @ehamai - so back to the original question of this thread: what is the guidance for setting WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in an ARM template that works for initial and subsequent deployments? For the Premium plan (not 100% sure about Consumption plan but believe it is the same), here is the matrix of what works/doesn't work:

if you deploy a new resource:

if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it fails with Required parameter WEBSITE_CONTENTSHARE is missing
if you supply both values, it works

if you deploy to an existing resource

if you supply neither setting, the deployment succeeds, but you end up with the Storage is not configured, Function scaling will be limited message
if you only supply WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, it succeeds (and appears to work fine afterwards) even though WEBSITE_CONTENTSHARE is supposed to be required
if you supply both values, it 'works' in that the ARM part does not fail, but it causes the multiple-restart issue and the MS guidance above is to not set WEBSITE_CONTENTSHARE on the updates

So there does not appear to be a way to have a single ARM template that works for both scenarios at the moment.

Hi Elliott
What I meant to say for the second point was that the WEBSITE_CONTENTSHARE should be define as an application setting but it should not be made a Deployment slot setting.
So it should not have the tick as below:
<EMAIL_ADDRESS>From: Elliott Hamai<EMAIL_ADDRESS>Sent: 22 June 2020 18:38
To: MicrosoftDocs/azure-docs<EMAIL_ADDRESS>Cc: Owain Winterbone (ITCS - Staff<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/azure-docs] WEBSITE_CONTENTSHARE should not be used accroding to support (#36458)
Warning: This email is from outside the UEA system. Do not click on links or attachments unless you expect them from the sender and know the content is safe.
@OwainWinhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOwainWin&data=02|01|o.winterbone%40uea.ac.uk|afedec71775f4f42d84108d816d2f967|c65f8795ba3d43518a070865e5d8f090|0|0|637284442665654874&sdata=x3m7KNp6hoQJMCqfb4aEUSNnmE6E5N7geDa8Vu7AUaw%3D&reserved=0 - Sorry I'm confused by your question. You asked if you should and should not include WEBSITE_CONTENTSHARE.
I believe you should have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined on both the production and staging slot.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F36458%23issuecomment-647674267&data=02|01|o.winterbone%40uea.ac.uk|afedec71775f4f42d84108d816d2f967|c65f8795ba3d43518a070865e5d8f090|0|0|637284442665664832&sdata=ctK99d4qO2YuIN%2F07lwuHC0wNut%2Fx8LjgLd7v55rTAM%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGFS4PEPPJE7NN6RO5D4SSLRX6JGNANCNFSM4IJGDPBQ&data=02|01|o.winterbone%40uea.ac.uk|afedec71775f4f42d84108d816d2f967|c65f8795ba3d43518a070865e5d8f090|0|0|637284442665664832&sdata=wXaMW%2Fx%2B5RXDtrfiQgHeZYtpc%2BhLyI9w6f9ut9NTFjM%3D&reserved=0.

@paulbatum

At initial creation of the resource via ARM, WEBSITE_CONTENTSHARE should be set. However after initial creation, this setting should be omitted from the ARM template (because if it was included, further executions of the ARM template might cause unexpected content swaps)

You do realize this kind of break the purpose of an ARM template, right?

That behavior is getting fixed, but it will probably take 1-2 months to make its way out. So in the meantime, the guidance I shared above (where you set it initially and then remove it from the ARM template) is applicable.

What is the final expected configuration here?
Can we get an announcement on Azure/app-service-announcements with proper configuration and official timeline once all this is actually deployed?

This is a big blocker for us. We need to be able to use the same ARM template to deploy to a new resource group that we would use to deploy to an existing resource group. We specifically run our ARM templates in Complete mode to help provide a little more context.
Right now, our ARM template looks sort of like this:
{
  "apiVersion": "2016-08-01",
  "type": "Microsoft.Web/sites",
  "name": "[variables('functionAppName')]",
  "location": "[variables('defaultLocation')]",
  "kind": "functionapp",
  "properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  },
  "resources": [
    {
      "name": "slotconfignames",
      "type": "config",
      "apiVersion": "2016-08-01",
      "dependsOn": [
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "appSettingNames": [
          "FunctionsDisabled"
        ]
      }
    },
    {
      "name": "staging",
      "type": "slots",
      "apiVersion": "2016-08-01",
      "location": "[variables('defaultLocation')]",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "AzureWebJobsStorage",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "AzureWebJobsDashboard",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "SomeSetting__Foo",
              "value": "[parameters('someSettings').foo]"
            },
            {
              "name": "SomeSetting__Bar",
              "value": "[parameters('someSettings').bar]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[ourapp.storageConnectionString(listkeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName')), '2015-05-01-preview').key1, variables('storageResourceName'))]"
            },
            {
              "name": "WEBSITE_CONTENTSHARE",
              "value": "[toLower(variables('functionAppName'))]"
            },
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "dotnet"
            },
            {
              "name": "FunctionsDisabled",
              "value": "1"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            }
          ]
        }
      }
    }
  ],
  "dependsOn": [
    "[resourceId('Microsoft.Storage/storageAccounts', variables('storageResourceName'))]",
    "[resourceId('Microsoft.Web/serverfarms', variables('functionAppName'))]"
  ]
}

Take note of the following details: We are specifying our configuration on the staging slot, not the production slot. What this allows us to do is deploy new settings (and updates to existing ones) to the staging slot first. So, our DevOps pipeline does this:

Step 1) Deploy ARM template to resource group
Step 2) Deploy functions app to staging slot
Step 3) Run some smoke tests against the staging slot
Step 4) Swap the staging and production slots

The problem, though, is that because WEBSITE_CONTENTSHARE is being set inside the ARM template, the production slot and the staging slot are immediately taking the new version of the application right after Step 2 (before a swap even occurs). I believe this is what people are talking about when they say "unintended swap operation".
We DO NOT want to set production slot settings in our ARM template, and we DO NOT want any of the production slot settings to be removed as a result of our ARM template running. The way that deploying ARM template in Complete mode works is that if we specify any settings for the production slot, then all the settings that are not explicitly specified are removed automatically.
I hope this all makes sense. We are currently attempting to remove WEBSITE_CONTENTSHARE from our ARM template, in hopes that the runtime will generate the value in all scenarios and no longer lead to "unintended swaps".

Hi all, I am the primary developer for deployment slots and I will address your concerns regarding setting WEBSITE_CONTENTSHARE, and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING:
Here is the official guidance:
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: This should always be set as it tells app service that you are using azure files for content storage.
WEBSITE_CONTENTSHARE:

This can now be omitted completely from you ARM templates for Consumption sku functions which will auto-generate the field and avoid unintended swaps. This means you can use the same template for creation and updates thereafter.

Unfortunately, we found that this auto-generation of WEBSITE_CONTENTSHARE was overlooked for Elastic Premium ski so the issue of having to include it during creation and omit it during updates still stands. The fix for this is currently rolling out and has reached half our fleet. It should be completely rolled out in the next 2 weeks and after than the guidance will be the same for both skus and WEBSITE_CONTENTSHARE can be omitted completely.

Hope that addresses some of your concerns!

@shubDhond Thank you so much. Can we get an official update on the documentation?

@shubDhond for windows consumption plans if I provide only WEBSITE_CONTENTAZUREFILECONNECTIONSTRING I get an error via arm template deployment saying WEBSITE_CONTENTSHARE is missing.
I dont need to use slots. If omitt both the deployment goes through but bu I get the warning "storage is not configured.function scalling will be limited".
Whats the guidance on consumption plans w.r.t those two parameters I am using .net core windows consumption plan ?

Ditto! I also get this error. When will this be fixed?

I have the same issue on consumption and elastic plan, it's causing us a lot of issues with automated deployments.

I have had some success with omitting WEBSITE_CONTENTSHARE for Premium when deploying settings directly in the Microsoft.Web/sites properties (siteConfig, appSettings), but not when specifying the settings as a separate resource using Microsoft.Web/sites/config with "type": "config".

@shubDhond This issue is definitely not fixed. On the Windows Consumption plan if you deploy a template with only the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and without the WEBSITE_CONTENTSHARE you will get the error "WEBSITE_CONTENTSHARE is missing".
Trying to use the App Service deployment tasks in Azure DevOps and setting only the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING will also produce a HTTP 400 Error.
Automation of Azure Function apps on the consumption plan is currently totally broken.

Having the same issue as @clawrenceks

We are also experiencing the same issue as @clawrenceks.
We also cannot set only WEBSITE_CONTENTAZUREFILECONNECTIONSTRING without WEBSITE_CONTENTSHARE through the Azure portal. We also have WEBSITE_RUN_FROM_PACKAGE set to 1.
I'm also not sure how this will work when you have your ARM template deployment mode set to Complete? Will it not remove the generated app setting WEBSITE_CONTENTSHARE?
Like most, we're also lost.

I now have my ARM template successfully deploying my function app into a Windows Consumption Plan. When deployed, the message Storage is not configured, Function scaling will be limited. Click to learn more is no longer displayed. Slot swaps are also working as expected.
My main findings from this process are:
If you currently have an Azure Function app WITHOUT the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE application settings, I believe the only way to fix this is to re-deploy your app, ensuring that the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING setting is in place as part of the application creation.
Having the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING in place as part of the resource creation is key. When using ARM my findings are that it must be deployed as an app setting during the main app service deployment, with a resource type of Microsoft.Web/sites. Having a separate resource type of Microsoft.Web/sites/config in your ARM template to deploy the application settings will not work.
I do not include the WEBSITE_CONTENTSHARE setting in my ARM template. This is created by the runtime when my ARM template is deployed. This is a sign that the deployment is working well. With the approach described here, I am able to deploy the initial resources and then re-deploy the template multiple times without receiving errors related to the WEBSITE_CONTENTSHARE setting.
A separate key requirement for me was the the production site application settings should only be deployed during the initial resource creation. The only way I wanted to get new (future) application settings into the production site is via a slot swap. To achieve this I added some logic into my ARM template to handle the following.

App settings in the ARM template will only be deployed to the production site during initial site creation, they will not be added to the production slot as part of future deployments.

App settings in the ARM template are always applied to the staging slot. They are then swapped into production using a swap slot.

To achieve the above, the appSettings for the production site in my ARM template are conditional. If the resource does not exist, I deploy the full set of app settings in the template (to ensure that the app service is created correctly). If the resource has already been created, I pass a null for the app settings. When deployed this retains the app settings that are already in place for the production site.

I'm also totally confused. If WEBSITE_CONTENTAZUREFILECONNECTIONSTRING is required for Consumption plans, but it cant be configured to stick to a slot, how am I supposed to swap between a staging and production slot where I want each one to run on a different storage account? This has been possible with Web Apps forever, and seems like a very common use case. As far as I can tell, swapping function app slots is completely broken / unusable until this is fixed. Would love for someone to tell me why / how I'm wrong though! I know the original issue references ARM templates, but this seems like a much more broad problem.

Same issue on Elastic Premium plan. Deploying to stage slot same ARM template with same WEBSITE_CONTENTSHARE makes production slot pointing to same binaries as stage slot.
Can't deploy without WEBSITE_CONTENTSHARE  at all as I get 2020-09-08T10:15:32.8385428Z ##[debug]Set-AzWebAppSlot : Operation returned an invalid status code 'BadRequest' error

I am confused. What is the correct thing to do?

If you're running on elastic premium or consumption, then you must meet one of the following criteria:
You must have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE defined
or
If you're using run from zip/package, then you must have "WEBSITE_USE_ZIP", "WEBSITE_RUN_FROM_ZIP", or "WEBSITE_RUN_FROM_PACKAGE" set to something other than empty, 0, or 1

as @ehamai says?
or

WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: This should always be set as it tells app service that you are using azure files for content storage.
WEBSITE_CONTENTSHARE:
This can now be omitted completely from you ARM templates for Consumption sku functions which will auto-generate the field and avoid unintended swaps. This means you can use the same template for creation and updates thereafter.
Unfortunately, we found that this auto-generation of WEBSITE_CONTENTSHARE was overlooked for Elastic Premium ski so the issue of having to include it during creation and omit it during updates still stands. The fix for this is currently rolling out and has reached half our fleet. It should be completely rolled out in the next 2 weeks and after than the guidance will be the same for both skus and WEBSITE_CONTENTSHARE can be omitted completely.
Hope that addresses some of your concerns!

as @shubDhond says?
I get an error if I have an azure function on consumption plan with no WEBSITE_CONTENTSHARE and i:

deploy ARM to staging slot
swap
redeploy to staging slot

Then it tells me that i need the WEBSITE_CONTENTSHARE. It is like it can't generate a share for the old production slot. I haven't tried to remove the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, because this thread says not to do it, except @ehamai, that tells me that i can do it, if i do a "WEBSITE_RUN_FROM_PACKAGE".
This is very confusing.

No matter what this spontaneous slots swap is very scary, anyway as we need to create both of these WEBSITE_ variables we are filling in ARM the latter ourselves too as per definition here. The webapp configuration diagonostic tool on the portal shows no error anymore.

#reassign: @mattchenderson

Any update on this?
We too have been adviced by Microsoft support that the "WEBSITE_CONTENTSHARE" property must be set. When it is not possible to set it as a slot setting this is quite problematic for our build pipelines and ARM templates. Please advice!

I agree too. It's really time for some explanation on how to use slots here!

I also agree, this thread was started over 15 months ago and there is still no stable resolution.
We cannot use slots until this has been properly resolved with a trusted solution, slots are a fantastic feature but they need to be reliable.

Hi all,
Extremely sorry for the delay in response here, this thread was not being monitored as well as it should have been.
To address the confusion, the behaviour described by @clawrenceks above is correct as of now. For sites which do not already have Azure Files storage configured, you will be required to provide both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE. Once these are provided and your app is now configured to run on Azure Files, you can omit WEBSITE_CONTENTSHARE from your templates thereafter to avoid inadvertently swapping your content.
The way the API currently works is that on site creation ('Microsoft.Web/sites' resource) if you provide WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and not WEBSITE_CONTENTSHARE, then a content share will be generated for you. However on updates of an existing 'Microsoft.Web/sites' resource or a 'Microsoft.Web/sites/config' resource, the API looks to see if there is already a value for WEBSITE_CONTENTSHARE for the app and if it isn't present, it throws an error.
I assume this was to protect against customers inadvertently wiping their content while switching to azure files, in the case they provide WEBSITE_CONTENTAZUREFILECONNECTIONSTRING  and we generate a new WEBSITE_CONTENTSHARE for them (essentially wiping their content since this share would be new). This is much safer during site creation because the site would start with a clean slate anyways and we don't risk wiping your content.
I can totally understand the confusion though for you all wishing to azure files. I will have to think of how to best address this while still keeping our update operations safe from wiping your content. As for now the guidance for you all who don't have azure files configured and wish to make the switch, you'll need to provide both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING   and WEBSITE_CONTENTSHARE for the initial switch and then the guidance would be the same to omit WEBSITE_CONTENTSHARE from your template thereafter.
If there are any suggestions as to how you'd like to see the update case handled, that would be greatly appreciated as well!

@shubDhond so we need to deploy connectionstring and contentshare appsettings on the first deploy to the production slot, but not on deploys after that. Is there any way of doing this automatically? Like detect if a resource has been deployed through ARM? Or do we manually need to pass this info into the ARM ( fx through a parameter that tells if this is the first deployment?

@mslot unfortunately I don't think its possible to tell within a template whether a resource already exists or not but this should be possible with this (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-tutorial-use-conditions) combined with a parameter passed to the template telling it whether the site is configured for Azure Files already. This can be determined by getting the site and seeing whether the app settings have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING  and WEBSITE_CONTENTSHARE.

@mslot unfortunately I don't think its possible to tell within a template whether a resource already exists or not but this should be possible with this (https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-tutorial-use-conditions) combined with a parameter passed to the template telling it whether the site is configured for Azure Files already. This can be determined by getting the site and seeing whether the app settings have WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE.

I really hope this gets fixed soon. It renders use of slots useless in my workflow. It needs to be fully automtatic. This solution is a hack workaround in my eyes and it doesn't make sense to introduce when it is working for webapps because it diverges to much on something that should just work the same introducing "black magic" for others coming in to a project.
I really hope this gets fixed so we can start using it.I think it keeps a lot of folks from using this feature.

@mslot I totally understand your pain with this and I'm sorry we weren't able to identify this issue sooner. I will speak to the devs who initially implemented this behaviour in the coming week and see if we can find a safe fix for this issue which could avoid the possibility of customers inadvertently moving to using an empty azure files share for their content. Once we have a proposed solution I'll update here.

@shubDhond I don't really understand the Azure Files "part" of this. I deploy my Azure Function project using Azure DevOps by first creating a deploymentslot, deploy to this and then swap. I'm using "RunFromPackage" deployment method and this does not seem to work when using a classic StorageAccount. I'm NOT using Azure Files and I seem to have the same problem related to the WEBSITES_CONTENTSHARE setting for the two slots.

Hi @cannehag could you please open a new issue for this? There may be some strange behavior happening with the RunFromPackage app setting being marked as sticky causing similar symptoms to what is described here. I would suggest a new issue so we don't add confusion here as the issues are likely unrelated.

@shubDhond Any update on this?

@shubDhond Any update on this?

I tried to do this as suggested but after I initially create the Function App with the "WEBSITE_CONTENTSHARE" setting I can't remove it. I tried removing it from the template and run it again and the deployment succeeds but the setting is still there. Same when I try to manually remove it from the portal.

I tried to do this as suggested but after I initially create the Function App with the "WEBSITE_CONTENTSHARE" setting I can't remove it. I tried removing it from the template and run it again and the deployment succeeds but the setting is still there. Same when I try to manually remove it from the portal.

@robinhultman to remove WEBSITE_CONTENSHARE (this will also switch to using xdrive instead azure files) please remove both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE from your template. Otherwise the API will use the cached value for WEBSITE_CONTENTSHARE.

@robinhultman to remove WEBSITE_CONTENSHARE (this will also switch to using xdrive instead azure files) please remove both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE from your template. Otherwise the API will use the cached value for WEBSITE_CONTENTSHARE.

#reassign:ggailey777

#reassign:ggailey777

I have tried so many combinations of these properties now and I recently managed to wipe everything in my function. What would be the negative consequence of always setting both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in ARM and using different values in WEBSITE_CONTENTSHARE for different slots, ie "share1", "share2" etc?

I have tried so many combinations of these properties now and I recently managed to wipe everything in my function. What would be the negative consequence of always setting both WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE in ARM and using different values in WEBSITE_CONTENTSHARE for different slots, ie "share1", "share2" etc?

In our setup we only modify the staging slot from the ARM template (leaving the production slot untouched) and then perform an automatic swap after code deployment. We sorted this issue using this setup:
                "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING": "[concat('DefaultEndpointsProtocol=https;AccountName=', parameters('functionAppStorageAccountName'), ';AccountKey=', listKeys(parameters('functionAppStorageAccountName'),'2019-06-01').keys[0].value)]",
                "WEBSITE_CONTENTSHARE": "[uniqueString(resourceGroup().id, deployment().name)]",

This ensures that each new deployment gets a valid but unique WEBSITE_CONTENTSHARE string which doesnt interfer with the primary (production) slot.

In our setup we only modify the staging slot from the ARM template (leaving the production slot untouched) and then perform an automatic swap after code deployment. We sorted this issue using this setup:
                "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING": "[concat('DefaultEndpointsProtocol=https;AccountName=', parameters('functionAppStorageAccountName'), ';AccountKey=', listKeys(parameters('functionAppStorageAccountName'),'2019-06-01').keys[0].value)]",
                "WEBSITE_CONTENTSHARE": "[uniqueString(resourceGroup().id, deployment().name)]",

This ensures that each new deployment gets a valid but unique WEBSITE_CONTENTSHARE string which doesnt interfer with the primary (production) slot.

@shubDhond Can we also have some guidance on what to do when the deployment is via Linux docker container on Elastic Premium - it seems to require the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING  and WEBSITE_CONTENSHARE to host the Kudu environment even it's not being used for the functions themselves; if the file share doesn't exist then the host doesn't even start (can provide support ticket references if needed)

@akoz0r is this the same thing as it should work out of the box? That each release to the slot gets its own unique CONTENTSHARE folder?

Here is a (currently) working ARM Template for Consumption plan when WEBSITE_RUN_FROM_PACKAGE is set to 1 with a deployment slot without specifying the WEBSITE_CONTENSHARE property:
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "parameters": {
    "appName": {
      "type": "string"
    }
  },
  "variables": {
    "functionAppName": "[parameters('appName')]",
    "hostingPlanName": "[parameters('appName')]",
    "applicationInsightsName": "[parameters('appName')]",
    "storageAccountName": "[parameters('appName')]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2019-06-01",
      "name": "[variables('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "kind": "StorageV2",
      "sku": {
        "name": "Standard_LRS"
      }
    },
    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2018-02-01",
      "name": "[variables('hostingPlanName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "Y1",
        "tier": "Dynamic"
      },
      "properties": {
        "name": "[variables('hostingPlanName')]",
        "computeMode": "Dynamic"
      }
    },
    {
      "type": "Microsoft.Insights/components",
      "apiVersion": "2015-05-01",
      "name": "[variables('applicationInsightsName')]",
      "location": "[resourceGroup().location]",
      "kind": "web",
      "properties": {
        "Application_Type": "web",
        "ApplicationId": "[variables('applicationInsightsName')]"
      },
      "tags": {
        "[concat('hidden-link:', resourceGroup().id, '/providers/Microsoft.Web/sites/', variables('functionAppName'))]": "Resource"
      }
    },
    {
      "type": "Microsoft.Web/sites",
      "name": "[variables('functionAppName')]",
      "apiVersion": "2018-11-01",
      "location": "[resourceGroup().location]",
      "kind": "functionapp",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
        "[resourceId('Microsoft.Insights/components', variables('applicationInsightsName'))]"
      ],
      "properties": {
        "name": "[variables('functionAppName')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
        "siteConfig": {
          "appSettings": [
            {
              "name": "FUNCTIONS_EXTENSION_VERSION",
              "value": "~3"
            },
            {
              "name": "FUNCTIONS_WORKER_RUNTIME",
              "value": "node"
            },
            {
              "name": "WEBSITE_NODE_DEFAULT_VERSION",
              "value": "~12"
            },
            {
              "name": "WEBSITE_RUN_FROM_PACKAGE",
              "value": "1"
            },
            {
              "name": "AzureWebJobsStorage",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
            },
            {
              "name": "APPINSIGHTS_INSTRUMENTATIONKEY",
              "value": "[reference(resourceId('microsoft.insights/components/', variables('applicationInsightsName')), '2015-05-01').InstrumentationKey]"
            },
            {
              "name": "NODE_ENV",
              "value": "production"
            }
          ]
        }
      },
      "resources": [
        {
          "type": "config",
          "apiVersion": "2018-11-01",
          "name": "slotConfigNames",
          "dependsOn": [
            "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
          ],
          "tags": {
            "displayName": "slotConfigNames"
          },
          "properties": {
            "storageAccountUrl": "",
            "appSettingNames": [
              "NODE_ENV"
            ]
          }
        },
        {
          "type": "slots",
          "apiVersion": "2018-11-01",
          "name": "staging",
          "location": "[resourceGroup().location]",
          "dependsOn": [
            "[resourceId('Microsoft.Web/sites', variables('functionAppName'))]"
          ],
          "properties": {
            "siteConfig": {
              "appSettings": [
                {
                  "name": "FUNCTIONS_EXTENSION_VERSION",
                  "value": "~3"
                },
                {
                  "name": "FUNCTIONS_WORKER_RUNTIME",
                  "value": "node"
                },
                {
                  "name": "WEBSITE_NODE_DEFAULT_VERSION",
                  "value": "~12"
                },
                {
                  "name": "WEBSITE_RUN_FROM_PACKAGE",
                  "value": "1"
                },
                {
                  "name": "AzureWebJobsStorage",
                  "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
                },
                {
                  "name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
                  "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'),';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName')), '2019-06-01').keys[0].value)]"
                },
                {
                  "name": "APPINSIGHTS_INSTRUMENTATIONKEY",
                  "value": "[reference(resourceId('microsoft.insights/components/', variables('applicationInsightsName')), '2015-05-01').InstrumentationKey]"
                },
                {
                  "name": "NODE_ENV",
                  "value": "staging"
                }
              ]
            }
          }
        }
      ]
    }
  ]
}

You have to provide the appsettings in the functionapp's properties/siteConfig/appSettings object instead of using the config type. Otherwise, you would get the Required parameter WEBSITE_CONTENTSHARE is missing. error message.

app plan kind: Linux
tier: Dynamic
os_type: linux
version: ~2
I'm getting this error when doing a swap slot
##[error]Error: Failed to swap App Service 'test-dev-func-we' slots - 'slot1' and 'production'. Error: InternalServerError - There was an unexpected error swapping slots 'slot1' and 'production' for site 'test-dev-func-we(slot1)'. Please try to cancel your swap operation. (CODE: 500)

Looking in azure for diagnosis for the failure:

Though according to the docs:
WEBSITE_CONTENTAZUREFILECONNECTIONSTRING
WEBSITE_CONTENTSHARE
Only used when deploying to a Premium plan or to a Consumption plan running on Windows. Not supported for Consumptions plans running Linux.
I am running a consumption based function app on Linux. This app setting should not apply to the function app I am deploying. Why am I getting the error above during performing a swap slot? Any help would be appreciated.

Note, when modifying an existing function, and you get Bad Request, try using a valid storage account file name, i.e. lowercase!
Also, not sure this is intended, but after moving to File storage, it only affects slot 0.  slot 1+ will need the connection string and share name added as well!  For now we are not proceeding to do this as our slot is a staging slot, and by moving to a storage account file share, we are unable to list the function and run them manually!  Staging does not need to be scaled at this time, though it would be nice to list and run functions anywhere.

I'm using the Portal and not a template. Deleting WEBSITE_CONTENTSHARE doesn't seem to work; the old value remains.
Consumption plan. Windows.
What can I do about this? Swapping can't work for me right now.

Thank you @danielstocker.
@realrubberduckdev,@ggailey777 - For more information, I am using "apiVersion": "2015-08-01" for app (type - Microsoft.Web/sites). In short, This is my ARM code:
{
"apiVersion": "2018-02-01",
"location": "[parameters('location')]",
"name": "[variables('testApiFunctionName')]",
"properties": {
"name": "[variables('testApiFunctionName')]",
"computeMode": "Dynamic"
},
"sku": {
"name": "Y1",
"tier": "Dynamic"
},
"type": "Microsoft.Web/serverfarms"
},
{
"apiVersion": "2015-08-01",
"type": "Microsoft.Web/sites",
"name": "[variables('testApiFunctionName')]",
"location": "[parameters('location')]",
"kind": "functionapp",
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', variables('testApiFunctionName'))]",
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]"
],
"properties": {
"serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('testApiFunctionName'))]",
"siteConfig": {
"appSettings": [
{
"name": "AzureWebJobsDashboard",
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountid'),'2015-05-01-preview').key1)]"
},
{
"name": "AzureWebJobsStorage",
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountid'),'2015-05-01-preview').key1)]"
},
{
"name": "WEBSITE_CONTENTAZUREFILECONNECTIONSTRING",
"value": "[concat('DefaultEndpointsProtocol=https;AccountName=', variables('storageAccountName'), ';AccountKey=', listKeys(variables('storageAccountid'),'2015-05-01-preview').key1)]"
},
{
"name": "FUNCTIONS_EXTENSION_VERSION",
"value": "~2.0"
},
{
"name": "APPINSIGHTS_INSTRUMENTATIONKEY",
"value": "[parameters('appInsightsInstrumentationKey')]"
},
{
"name": "FUNCTIONS_WORKER_RUNTIME",
"value": "dotnet"
}
]
}
}
},

@hb66772-home Won't WEBSITE_CONTENTSHARE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING be replaced with nothing during the swap if you don't set it in the slot settings?

I have the following code:
var appSettings = [
  {
    name: 'WEBSITE_ENABLE_SYNC_UPDATE_SITE'
    value: 1
  }
  {
    name: 'SCM_TOUCH_WEBCONFIG_AFTER_DEPLOYMENT'
    value: 0
  }
  {
    name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
    value: reference(resourceId(appInsightsResourceGroup, 'microsoft.insights/components/', appInsightsName), '2015-05-01').InstrumentationKey
  }
  {
    name: 'AzureWebJobsStorage'
    value: 'storageAccount'
  }
  {
    name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING'
    value: 'connectionstring'
  }
  {
    name: 'FUNCTIONS_WORKER_RUNTIME'
    value: 'dotnet'
  }
  {
    name: 'FUNCTIONS_EXTENSION_VERSION'
    value: '~4'
  }
]

var stagingSettings = [
  {
    name: 'WEBSITE_CONTENTSHARE'
    value: toLower('functionApp-staging')
  }
  {
    name: 'AzureFunctionsJobHost__extensions__durableTask__hubName'
    value: 'hubStaging'
  }
]

var productionSettings = [
  {
    name: 'WEBSITE_CONTENTSHARE'
    value: toLower('functionApp')
  }
  {
    name: 'AzureFunctionsJobHost__extensions__durableTask__hubName'
    value: 'hub'
  }
]

module functionAppTemplate 'functionApp.bicep' = {
  name: 'functionAppTemplate'
  params: {
    name: '${functionAppName}'
    kind: functionAppKind
    location: location
    servicePlanName: servicePlanName
    secretSettings: union(appSettings, productionSettings)
  }
  dependsOn: [
    servicePlanTemplate
  ]
}

module functionAppSlotTemplate 'functionAppSlot.bicep' = {
  name: 'functionAppSlotTemplate'
  params: {
    name: '${functionAppName}/staging'
    kind: functionAppKind
    location: location
    servicePlanName: servicePlanName
    secretSettings: union(appSettings, stagingSettings)
  }
  dependsOn: [
    functionAppTemplate
  ]
}

functionApp.bicep

resource functionApp 'Microsoft.Web/sites@2018-02-01' = {
  name: name
  location: location
  kind: kind
  properties: {
    serverFarmId: resourceId('Microsoft.Web/serverfarms', servicePlanName)
    clientAffinityEnabled: false
    httpsOnly: true
    siteConfig: {
      use32BitWorkerProcess : false
      appSettings: secretSettings
    }
  }
  identity: {
    type: 'SystemAssigned'
  }
}

functionAppSlot.bicep

resource functionAppSlot 'Microsoft.Web/sites/slots@2018-11-01' = {
  name: name
  kind: kind
  location: location
  properties: {
    clientAffinityEnabled: true
    enabled: true
    httpsOnly: true
    serverFarmId: resourceId('Microsoft.Web/serverfarms', servicePlanName)
    siteConfig: {
      use32BitWorkerProcess : false
      appSettings: secretSettings
    }
  }
  identity: {
    type: 'SystemAssigned'
  }
}

With this, I see the functions in production slot getting removed during deployment. What am I missing?

Is this is resolved or any update?
We are using Terraform AzureRM provider 3.14, but still we are facing same scenario.
As per design we have different dedicated Fileshares per funapp & slot; hence we need to assign WEBSITE_CONTENTSHARE for the Fun_App and its Slots as well.
So whenever we are deploying via TF the Apply goes exactly as per Plan but during the same timestamp Staging-slot Contentshare gets UNINTENDED_SWAP erroneously(which is not present at TF plan or TF codebase) with the FunApp-prod.

My The parameter WEBSITE_CONTENTSHARE has an invalid value error was actually caused because my Function App name had the word "FunctionApp" and is a reserved word I guess. So bad idea to use "MyFunctionAppTest" or things like that and specially to assign the same name to the WEBSITE_CONTENTSHARE value.

The docs should now be correct and hopefully helpful on this issue. Please reopen or create a new issue if you find that is not the case. #please-close

according to the https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#website_contentshare, "When you don't set a WEBSITE_CONTENTSHARE value for the main function app or any apps in slots, unique share values are generated for you. Not setting WEBSITE_CONTENTSHARE is the recommended approach for an ARM template deployment."
but without setting it I got this error on deployment:
##[error]undefined: Required parameter WEBSITE_CONTENTSHARE is missing.

according to the https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#website_contentshare, "When you don't set a WEBSITE_CONTENTSHARE value for the main function app or any apps in slots, unique share values are generated for you. Not setting WEBSITE_CONTENTSHARE is the recommended approach for an ARM template deployment."
but without setting it I got this error on deployment:
##[error]undefined: Required parameter WEBSITE_CONTENTSHARE is missing.

I think I only add it on the first deployment, subsequent deployments does not include it


raylib drawline & alpha

Issue description, screen & code
Since the upgrade to version 6, the alpha value of colors is no longer considered.
exemple (alpha = 15) :
static void ApplyScanlineEffect(int screenWidth, int screenHeight, int scanlineHeight)
    {
        Raylib.BeginBlendMode(BlendMode.AddColors);
        for (int y = 0; y < screenHeight; y += scanlineHeight * 2)
        {
            Raylib.DrawLine(0, y, screenWidth, y, new Color(128, 128, 128, 15));
        }
        Raylib.EndBlendMode();
    }

result :

Environment
Win 10, RaylibCS 6

I've tested blending functions on older projects (running on <IP_ADDRESS>) and it works same as 6.0.0 version
I do not know what is your desired result, but shouldn't you use Alpha blending?
With Alpha blending and line with new Color(128, 128, 128, 128):

I chose the wrong blend mode; we can close the ticket, the mistake is on my part ;)


device no longer working, no logs or whatever since latest hass.io version under synology

Hi,
Since latest version of hass.io and synology my zigbee2mqtt is not working anymore. Before I was using the special version from another repositories that I can't remember from now But when trying to use this version, I got mqtt connected, I see my sensor but the state of the sensor is not updated. Is there a way to debug what is going on ? I checked inside the docker image, and my /dev/ttyACM0 for my CC2531 is there, so it should be not the problem. Anyone having same problem as me ? I'm using mosqitto server addon too.

I tried to use zigbee2mqtt on the computer directly and it works. I can see the pairing device. But not on synology.

You can try looking in hassio system hardware to see how the serial port in named o your synology.

You can try looking in hassio system hardware to see how the serial port in named o your synology.


Feature-request: Recursive mail merges

I'd like to be able to have a mail merge field in my word document template, and then merge in new mail merge fields.  In other words something like this:
In template:
List of activities:
<<Field_1>>

And then be able to replace <>  new merge fields like:
<<Activiy_1_title>>
<<Activity_1_description>>
<<Activity_1_milestone>>
<<Activity_1_timeline>>
Or perhaps there is a better way like using a python variable to insert a mail merge field?
Expected Behavior
I'd like to be able to insert new mail merge fields into a word document, to make a new template that would then later be subjected to a second, standard mail merge from an excel/csv file.
Current Behavior
It's unclear to me how I can insert a mail merge field into a template using the package
Possible Solution
This could jut be an education problem for myself, but I searched around and couldn't find an answer
Context
I have to generate a lot of word document quotes for different kinds of services, so I'm trying to automate the setting up of a template, which then needs to be updated for each customer with different numbers of activities each time.  These activities then have their own titles, descriptions, timelines, etc.
So what I want to have is the following flow:
Start: Base Template -> modified template with mail merge fields -> final merge using data from excel that contains descriptions, titles, etc
Your Environment
I'm using windows and either stable version of python

I have the same requirement: my job requires me to produce a lot of .docx files containing {MAILMERGE} fields.
However does it need to be a recursive mailmerge? The initial template could be marked up with simple text sequences e.g. {{field_1}} or [[header]], and only the output files need proper Ctrl-F9 {MAILMERGE} fields.
I think inserting Ctrl-F9 fields like {MAILMERGE} might be outside the scope of this module, which is for populating those fields. Still looking for a module for doing this!


Add custom SSH URL mapping

Context
We have a customer that hosts their GitLab and Wharf instance in the same Kubernetes cluster. Because of techincal difficulties with the firewalls and other services, they cannot talk to each other via the internet. They can only talk to each other in the internal kubernetes network.
Currently the Git SSH URL is taken from the ssh_url_to_repo property (GitLab docs: https://docs.gitlab.com/ce/api/projects.html#get-single-project), as can be seen here:
https://github.com/iver-wharf/wharf-provider-gitlab/blob/413c450167f12fc9978c6fe75b192b7e993f891a/mapper.go#L20-L29
Suggested implementation
Add optional config flag, ex WHARF_GIT_URL_TEMPLATE, that does a basic search and replace on the SSH key using some different fields.
We could use the text/template Go package for this.
Example usage
  env:
    - name: WHARF_GIT_URL_TEMPLATE
      value: "ssh://gitlab.default.svc.cluster.local:2222/{{ .path_with_namespace }}.git"

Or if we want to use the Project type directly:
  env:
    - name: WHARF_GIT_URL_TEMPLATE
      value: "ssh://gitlab.default.svc.cluster.local:2222/{{ .PathWithNamespace }}.git"

(https://pkg.go.dev/github.com/xanzy/go-gitlab#Project)
Considerations
This needs to be well documented as soon as it's implemented.
How do we make sure we're not colliding with Wharf's own variable syntax? We have been experimenting with the idea of changing the variable syntax, as can be seen here: https://iver-wharf.github.io/wharf-notes/different-variable-syntaxes Do we want to change Wharf's variable substitution to use Go's text/template package instead, or do we stick with a custom templating system?
This should also be implemented in our other providers, so picking a stupid-simple variable substitution syntax is key.
Needs an RFC for this.

On second thought, this should probably be stored in the database and not inside the provider's config. Better to let users configure it via the web or REST interface

This was fixed in wharf-api v5.0.0 (https://github.com/iver-wharf/wharf-api/issues/114)


NCD entry at FAIRshring.org

What to do about updating this entry https://fairsharing.org/bsg-s000202/ about NCD?

do we link to it somewhere (old, but relevant links)
update the information there to indicate cd std is in development?

I will ask the group. NCD was implemented (by BHL) and as such is in use. So maybe better to have a new entry at fairsharing.org and link the two entries...


LOGGER in main.py is not defined

Hi, I tried the extension, but it did not work at first. I then investigated the code a bit and noticed that LOGGER referenced here is not defined in the code, probably causing the extension to terminate there. Removing the line makes the extension to work as expected.

Hi, thanks for the report! You are right, it should have been in a commit which is dev-branch only but it looks like I added the line to the wrong commit. It is removed now.
Have a nice day and stay healthy!


Dockerfile initial version.

Solves movableink/doorman#31
See also movableink/doorman#30
How to test:
$ docker build -t=doorman . # Builds the Docker image locally
$ docker run -d --name=doorman_test_backend pataquets/drupal # Spin up a local test backend (Drupal 7).
$ docker run -d -p 8080:80 -e DOORMAN_LISTEN_PORT=80 -e DOORMAN_MODULES=password -e DOORMAN_PASSWORD_TOKEN=1234 -e DOORMAN_HOSTNAME=http://your.hostname.com:8080 -e DOORMAN_PROXY_HOST=backend -e DOORMAN_PROXY_PORT=80 --link=doorman_test_backend:backend --name=doorman_test_proxy doorman # Launches exposed Doorman (tip: use SQLite to finish Drupal install)

Added test instructions.
TODO after merging:

Document / add usage example
Create Docker Hub automated build

Bump.
My image got outdated. Having a canonical Dockerfile and setting up an official Docker image would be a convenient way to stay up-to-date.

Since you already have a Docker Hub account, you can set an 'Automated Build' to keep Doorman image up-to-date with latest commits.

How about setting up a 'movableink/doorman' automated build on Docker Hub?

@mnutt: ping?


Number support

Renames the component to have a different prefix as 3rd party libs shouldn't use app.
Allows specifying a different mode as seconds/minutes/hours/days/weeks/months/years which will allow the input to be a numeric type.

ISO8601 durations are great, but a lot of APIs use seconds for example to express duration and it would be nice to not have to bring in something like moment.js to translate the durations before submitting the value to the API.

I fixed the indentation issues, moved mode into options, and split out parse and generate into separate functions.

Feel free to take the pieces you'd like. We've decided to abandon this component in favor of something a little simpler and I likely won't have time to do what you're asking. Cheers!

@vincentjames501 that's a shame :( but thanks anyway for your contribution


Db Connected Rest service empty response on http 200.

I've created 3 database tables. City, State, Country. Inserted one row for each of them. Created those 3 db connected rest services, but when i try to use the get method for State, doesn't matter if using the id param or not, it returns empty response with http 200.
Didn't modify anything to any of the services, and the other ones are working. Also tried to delete it and create again. My guess is that its some bug with the service name (State might be a reserved word or something).
Apart from that, couldn't figure out what is going on. Tried to var_dump $collection before the return of RestController and it actually returns the expected collection with one result in it, but couldn't figure out to where this object is returned.
@EDIT
Figured it out.
json_encode is failing in https://github.com/zendframework/zf2/blob/master/library/Zend/Json/Json.php#L119
with message:
Malformed UTF-8 characters, possibly incorrectly encoded.
which then i figured out that was because my incorrect database adapter charset configuration.
Anyway, it would be very nice to get this json_encode error as a ApiProblem instead of a blank response with http 200.

:+1:
Home / Database Adapters / Charset <- utf8

@olavocneto this is a very old issue. I actually knew i could configure it, but the error isn't very clarifying. The problem was the error reporting itself. That happens because how json_encode works and this behavior being ignored by apigility.

Yes, I agree. In fact, you helped me. Thank u!

even this is an old issue and I could fix my error with the help of this issue, I have to answer it:
@weierophinney: You will get no error if you have active HalJson, no logging no output
only a blank 200 page. If you switch only to json for content negotiation
you will the error with the malformated character. Does the HalJson have different error handling.
possibly apigiity can show the same error even HalJson ist active by default.
Thank you

Bump

@weierophinney I actually found out my code doesn't use JsonModel. I'm using Apigility + Doctrine (using the api-skeleton libs). By the time the payload gets to the JsonRenderer (Zend View) it's just a plain PHP array, and that piece of code does NOT handle JSON errors whatsoever, which is kind of suprising. Source here: https://github.com/zendframework/zend-view/blob/master/src/Renderer/JsonRenderer.php#L154
Should the system be hydrating a JsonModel instead of using a plain PHP array? Or should the code in JsonRenderer be fixed to throw errors? I lean towards the latter but let me know what you think..

I'm getting the same... I have two tables one with accents and another without.
If I try to do a fetchAll on accents table returning a Pagination Collection I get a blank response body.
If I change the content negociator from HAL to Json, I get a list of empty objects.
But everything works fine with the table without accents.
Ps:

My table is utf8_general_ci
My driver adapter is Mysqli with utf8 as charset

Does anybody discovery a way to fix this?
Thanks.

This repository has been closed and moved to laminas-api-tools/api-tools; a new issue has been opened at https://github.com/laminas-api-tools/api-tools/issues/70.


Support unicode dashes in search box (for example chr2:166863579–166864271)

Other sites or docs sometimes have unusual dashes, and copy-pasting these into the search box results in confusing behavior where the browser can't parse a normal-looking interval string.
I've found one way to handle these is with Unicode char classes

Cool, did not know about Unicode character classes.
Also found this article describing the properties available to match on: https://javascript.info/regexp-unicode#unicode-properties-p


[19.03] kde-applications: 18.12.1 -> 18.12.3

Motivation for this change
Backporting https://github.com/NixOS/nixpkgs/pull/56155 was mentioned https://github.com/NixOS/nixpkgs/pull/56155#issuecomment-467182759

@lheckemann
Since it's a minor version bump though I suppose we can still backport it to 19.03 after the branch-off.

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Going for it :smile:


Update how-to-deploy-on-AWS.md

suggestions and fixes to the instructions, as I followed along making a new aws instance

Keep tunned (refresh every week) to https://verdaccio.org/contributors :) every contribution is recognized with your avatar on that page.


 Please wait...
    ________________________________________________________________

0/6 [>---------------------------]   0%Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table
Migrating: 2015_04_12_000000_create_orchid_users_table
Illuminate\Database\QueryException  : SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'json null' at line 1 (SQL: alter tabl
e users add last_login timestamp null, add permissions json null)
at C:\xampp\htdocs\codweltnew2\vendor\laravel\framework\src\Illuminate\Database\Connection.php:664
660|         // If an exception occurs when attempting to run a query, we'll format the error
661|         // message to include the bindings with SQL, which will make this exception a
662|         // lot more helpful to the developer instead of just the database's errors.
663|         catch (Exception $e) {

664|             throw new QueryException(
665|                 $query, $this->prepareBindings($bindings), $e
666|             );
667|         }
668|

Exception trace:
1   Doctrine\DBAL\Driver\PDOException::("SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'json null' at line 1")
C:\xampp\htdocs\codweltnew2\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOConnection.php:63
2   PDOException::("SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'json null' at line 1")
C:\xampp\htdocs\codweltnew2\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\PDOConnection.php:61
Please use the argument -v to see more details.


feat: db graceful shutdown

fx.Lifecycle hook to close db
fix package description prefix
fix default config file definition

fix #45

Codecov Report

Merging #46 (81b7522) into main (91c83ad) will not change coverage.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@           Coverage Diff           @@
##             main      #46   +/-   ##
=======================================
  Coverage   72.89%   72.89%
=======================================
  Files          20       20
  Lines         332      332
=======================================
  Hits          242      242
  Misses         73       73
  Partials       17       17

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Pydantic 2.0 incompatible with morecantile

I have run into issues using rio-cogeo due to pydantic 2+ breaking morecantile. Morecantile maintainers have recently pinned dependent pydantic versions at 1.X:
https://github.com/developmentseed/morecantile/issues/127
rio-cogeo now has a hard pydantic 2+ requirement.

Latest version (5.0) has direct requirements for pydantic 2.0
Version 4.0.1 has requirement for pydantic 1.0
Earlier version might have incompatible requirements but you're telling which one you are using neither the error message you are getting


added test cases for error handler

Added new UTs for Error handler

Naming convention is not at all followed. Please correct it in overall PR


Support ruby-2.5

This PR is a replacement for https://github.com/backup/backup/pull/922.
I investigated about the strange warns reported into the previous PR and with ruby-2.5 the Thread.report_on_exception default value changed from false to true so this is the main reason about these strange warns.
Digging into it I discovered that the warns were generated by a stubbed exception into a spec which was trying to simulate a network error.
Note: Now I've muted the warns only for this single spec.
So there isn't any issue with ruby-2.5 and it seems working correctly.

I'd like this very much

Any chance this will be merged and deployed?

Since I desperately need this, I will install the gem from @dalpo repo / branch. Too bad this project seems to be abandoned even though there was an effort to transfer it to maintainers :(

@dalpo I'm in the process of upgrading the travis-ci builds and the dependencies.
At the moment, the failing test this fixes is in pending state. But I'd love to merge your fixe if you were kind enough to rebase it :)
Also, please note that we've changed our contribution policy, it's much easier to become a committer: See Becoming a contributer


[Feature Request]: Add rate us/feedback option

Is there an existing issue for this?

[X] I have searched the existing issues

Feature Description
in the footer add feedback option for better user interaction
Use Case
Assign this to me under gssoc ext and hacktoberfest
Benefits
No response
Add ScreenShots
No response
Priority
Medium
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC-EXT contributor
[X] I'm a HACKTOBERFEST contributor
[X] I have starred the repository

@Aditijainnn go ahead


separate nix from nixos

i want to be able to use nix without having to install the whole os every time
also, somehow hosting the repo and configuring it so you can do nix-shell $URL to boot into my configuration.................................amazing (see https://github.com/bouk/b)

https://discourse.nixos.org/t/automating-home-manager-setup/12245/6

do this as needed: if i need to use macos or windows I will set this up first

export as part of the flake - just the modules, if not an entire configuration?  https://github.com/nix-community/home-manager#nix-flakes


Extend mist list options to mist download for automation purposes

I'm debating with myself if this is necessary or not, so I wanted to propose it and see your thoughts.
I'm looking to have the --export and --quiet options that are available with mist list to be extended to mist download.
The idea is that if I were to automate the creation of install media, I would want the details of the download saved as an artifact.
For example, if I were to run sudo mist download 12 --image --image-name 'Install_macOS_%VERSION%-%BUILD%.dmg' --quiet --export $PWD/export.json the result would be same output as mist list 12 --latest --quiet --export $PWD/export.json, but with the details of what was downloaded.
My debate is if this is useful. Is it possible that the results of mist list 12 --latest --quiet --export $PWD/export.json would be different than what would be downloaded with sudo mist download 12 --image --image-name 'Install_macOS_%VERSION%-%BUILD%.dmg' --quiet --export $PWD/export.json?
Another thought I had was to have an option to export as environment variables for the 3 variables that can be used with names, something like $MIST_NAME, $MIST_VERSION, $MIST_BUILD that would be the same as %NAME%, %VERSION%, %BUILD%.

I like the idea of exporting the mist download output to a json/yaml file, complete with the following:

Downloaded file(s) + sizes + paths
Temp file(s) created
Generated app + dmg + pkg paths

In theory, this exported (structured) output can be consumed by some other system for reporting / analytics etc.
Also like the optional --quiet flag to suppress standard output.
Will look into this!

Finally got some traction!

mist download --quiet will suppress all standard output
mist download --export  <export> will export the downloaded Firmware / Installer and provided options

Here's an example of a successfully downloaded macOS Firmware IPSW file:
{
  "firmware" : {
    "beta" : false,
    "build" : "21D62",
    "date" : "2022-02-10T18:25:00Z",
    "name" : "macOS Monterey",
    "signed" : true,
    "size" :<PHONE_NUMBER>7,
    "url" : "https:\/\/updates.cdn-apple.com\/2022WinterFCS\/fullrestores\/002-66272\/FB0B40F5-49EB-421B-81EC-8B56B8468D3C\/UniversalMac_12.2.1_21D62_Restore.ipsw",
    "version" : "12.2.1"
  },
  "options" : {
    "exportPath" : "\/Users\/nindi\/Desktop\/mist-firmware.json",
    "firmwarePath" : "\/Users\/Shared\/Mist\/macOS Monterey-12.2.1-21D62.ipsw",
    "force" : true,
    "includeBetas" : true,
    "keychain" : "",
    "kind" : "firmware",
    "outputDirectory" : "\/Users\/Shared\/Mist",
    "quiet" : true,
    "temporaryDirectory" : "\/private\/tmp\/com.ninxsoft.mist.12.2.1-21D62"
  }
}

And here's an example of a successfully downloaded macOS Installer Application Bundle:
{
  "installer" : {
    "beta" : false,
    "build" : "21D62",
    "date" : "2022-02-18",
    "distribution" : "https:\/\/swdist.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/002-66265.English.dist",
    "identifier" : "002-66265",
    "name" : "macOS Monterey",
    "packages" : [
      {
        "size" : 5119,
        "url" : "https:\/\/swcdn.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/Info.plist"
      },
      {
        "size" : 1290934,
        "url" : "https:\/\/swcdn.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/MajorOSInfo.pkg"
      },
      {
        "size" : 188,
        "url" : "https:\/\/swcdn.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/InstallInfo.plist"
      },
      {
        "size" :<PHONE_NUMBER>8,
        "url" : "https:\/\/swcdn.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/InstallAssistant.pkg"
      },
      {
        "size" : 2764685,
        "url" : "https:\/\/swcdn.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/UpdateBrain.zip"
      },
      {
        "size" : 1945574,
        "url" : "https:\/\/swcdn.apple.com\/content\/downloads\/11\/62\/002-66265-A_HKQGKQG1Z4\/orfaxf4k2gvqeatuhx6agnr5nlti3rwq93\/BuildManifest.plist"
      }
    ],
    "size" :<PHONE_NUMBER>8,
    "version" : "12.2.1"
  },
  "options" : {
    "application" : true,
    "applicationPath" : "\/Users\/Shared\/Mist\/macOS Monterey-12.2.1-21D62.app",
    "catalogURL" : "https:\/\/swscan.apple.com\/content\/catalogs\/others\/index-12-10.16-10.15-10.14-10.13-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz",
    "exportPath" : "\/Users\/Shared\/Mist\/mist-installer.json",
    "force" : true,
    "image" : true,
    "imagePath" : "\/Users\/Shared\/Mist\/macOS Monterey-12.2.1-21D62.dmg",
    "imageSigningIdentity" : "Developer ID Application: Nindi Gill (7K3HVCLV7Z)",
    "includeBetas" : true,
    "iso" : true,
    "isoPath" : "\/Users\/Shared\/Mist\/macOS Monterey-12.2.1-21D62.iso",
    "keychain" : "",
    "kind" : "installer",
    "outputDirectory" : "\/Users\/Shared\/Mist",
    "package" : true,
    "packageIdentifier" : "com.ninxsoft.macos-monterey-12.2.1-21d62",
    "packagePath" : "\/Users\/Shared\/Mist\/macOS Monterey-12.2.1-21D62.pkg",
    "packageSigningIdentity" : "Developer ID Installer: Nindi Gill (7K3HVCLV7Z)",
    "quiet" : true,
    "temporaryDirectory" : "\/private\/tmp\/002-66265"
  }
}

Note: Any error along the way will result in mist throwing an exception, and exiting early (thus not exporting any results).


Docker install for NUC

Hi, how to install it in a docker on NUC (amd64 x86_64)?

I am not able to start it with docker run or compose yaml file on debian. Can you please give some examples?

Any ide?


Svnapot reserved encodings

The last row of Table 5.1 "Page table entry encodings when pte.N=1" says that for i>=1, which refers to all bits of the physical address above bit 20, all encodings of pte.ppn[i] are reserved.
Shouldn't this apply only when the lower pte.ppn bits are all 0? Which is already considered reserved by the previous line in the table.
Otherwise it would be impossible to create a NAPOT page because all possible values of the 9 bits of pte.ppn[1] are always reserved.
I think the last line of this table should be removed.

My confusion here was that the restriction on pte.ppn[1] refers to a different PTE (i.e. the second level of Sv39 tablewalk) than the restrictions on pte.ppn[0]. "How can it be useful to reserve all possible values of that field?" I asked. But they're only reserved in the non-leaf PTEs if they have N=1. (Because NAPOT pages >=2MB are not supported [yet]). It makes sense to me now.


Why no mouse right click?

Thanks for creating GeonBit.UI, it's absolutely amazing so far!
Is there a reason why Entity.Update() and InputHelper has no support for right mouse button actions (click, down, pressed & released) ?

Thanks, glad you like it! :)
I have yet to see a reason for a right click in the entities I have, usually right click is used to open a special menu or do alternative action, and there's nothing like that on GeonBit.UI. Maybe one day I'll add right-click options to text inputs (cut / copy / paste) but that's a feature on its own.
Can you provide an example of an entity you feel missing a right click, and what would you have the right click action do?
PS. InputHelper does support right click, in its mouse-related functions you can send button code (defaults to left mouse button).

Special menu is the thing I'm trying to create for a custom entity that is derived from the Icon entity. For example if you have a potion in your inventory and left click uses it, right click would open a small special menu which has addional actions for it, like drop, etc. Buttons could benefit from a right click special menu too.
Oh you're right, for some reason I didn't realise that was the default.
I know I could override the Update() in my custom entity to make right click a thing but I think that would lead to a lot of code duplication, probably..

To avoid code duplication you can call base.Update(...) from your custom Update() function, and just append your extra logic after.
I'm closing this ticket as I feel your questions were answered, but if not feel free to reopen :)
Cheers.


Refactor JCK ansible scripts

Make similar modifications to the two JCK makefiles as was done in https://github.com/AdoptOpenJDK/openjdk-infrastructure/pull/100 for the regular ones
At the very least this should move them into an AdoptOpenJDK_JCK_Playbook subdirectory. OS-specifics can be abstracted out later. The services (and firewall rules if possible) can be converted to ue with_items and potentially the hosts for the Firewall rules could be moved to an external variable.

Closing this as we are not running the JCK at present so this is is not required