search

projectkudu / kudu

Kudu is the engine behind git/hg deployments, WebJobs, and various other features in Azure Web Sites. It can also run outside of Azure.
Apache License 2.0
3.12k stars 654 forks source link

SCM_DISABLE_DEPLOY_ON_PUSH does not work on Azure #1463

Closed garunski closed 4 months ago

garunski commented 9 years ago

After adding SCM_DISABLE_DEPLOY_ON_PUSH key and setting it to 1, the build process still went on to create the command to execute and build and deploy the site. Checked the Kudu environment variables and indeed SCM_DISABLE_DEPLOY_ON_PUSH=1 was part of them. Checked the Kudu version and it is 42.40114.1341.0. By making a guess from the version history page the S42-QFE2 version corresponds to the 42 in the sites version. While the code for the check is in the source maybe its not deployed to Azure? And if it is, how does this feature work?

suwatch commented 9 years ago

Can you clarify if you are doing git push directly to Kudu? No via continuous integration with github or sorts.

garunski commented 9 years ago

I am doing a continuous integration with BitBucket.

suwatch commented 9 years ago

This feature only targets if one is pushing to Kudu directly. Could you explain you scenario a bit and we could consider addressing it?

davidebbo commented 9 years ago

For now, I clarified the doc to mention this: https://github.com/projectkudu/kudu/wiki/Configurable-settings

garunski commented 9 years ago

I have continuous deployment set up to the site. Currently every commit will build the site and deploy the changes. In some cases I would like to wait on releasing the latest changes. Currently I set up a "stage" deployment slot and do continuous deployment on that site and do a Swap to push the latest changes to "production". There are a myriad of way for me to work around this issue including a branching strategy with Git and using the API doing the pushes. It would be easy and simple if this flag just worked for all deployments. Not having this flag work makes deployment and setup complicated for me because of the number of websites that a decent deployment strategy requires. Such as having at least two websites with traffic manager for fail over in case any of the data centers have issues. In that case i would need four websites, two stage and two production with only one really being used, and three sitting idly and using up resources. With this switch I could run two websites and have only one sitting idly.

jvano commented 4 months ago

Hi

Kudu will continue to run in Azure App Service. However, this repo will no longer be maintained. If the problem persists and is related to running on Azure App Service, please open a support incident in Azure: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

This way we can better track and assist you on this case

Thanks,

Joaquin Vano Azure App Service