I've setup a continuous deployment between Bitbucket and the new Azure portal (preview). It works great but when I checked Bitbucket, I noticed that it created a services rather than a webhook but in the service section and the following message is displayed:
In the future, you will not be able to create POST or Pull Request POST services from this screen, as Bitbucket's new and improved webhooks will replace these services. Existing POST services will continue to function as expected for now. To create a new webhook, refer to the documentation for Bitbucket's updated webhooks.
But I can't figure out how to create a webhook in the new Azure Portal. Every articles on the web that I have found are all explaining it based on the old ('current') portal.
Any ideas on how I can create a webhook instead? Not critical since it's working but considering the message displayed in Bitbucket, I thought I'd look into it now rather than wait for bitbucket to disable this feature.
Thanks.
Login to Old Azure Console, https://manage.windowsazure.com
Goto Configure
Find out DEPLOYMENT TRIGGER URL
You can use this trigger URL to setup webhook in BitBucket
But I don't think you have to worry much as Azure will automatically upgrade their services to do this automatically, that is what managed cloud means, we are paying them to manage this.
Related
I've been looking around for a while now but I can't seem to find a way to get push messages from the azure devops team for their release notes regarding the azure devops service. I would like to be able to incorporate the changes/release notes into a teams channel (the app). I was surprised by a change to the GET git repo list api url. Which broke some stuff.
I can't really find any way to subscribe to changes to their service, other then to watch the ms-documentation github repo.
What are the ways in which you make sure you are not surprised by breaking changes?
Testing this API: Repositories - List, we can still retrieve git repositories under this project.
In addition, sprint-184-update for Azure DevOps service brings new feature: Disable a repository.
And by reference to this doc: Build Azure Repos Git or TFS Git repositories, Azure DevOps enables some limitation to Azure Pipelines regarding to Azure Repos Git repository like Limit job authorization scope to referenced Azure DevOps repositories. Please check it.
Update>>This API: GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=6.1-preview.1 does the same thing to retrieve git repositories.
And Azure DevOps service doesn't provide notifications about repositories changes(Add, Delete), see: Supported subscriptions for details. Also currently official released APIs list here: Azure DevOps Services REST API Reference.
BTW, you can create a new suggestion ticket here. The product group will review these tickets regularly, and consider take it as roadmap.
I have a situation :
Developing and Deploying the HttpTrigger based logicApp using visual Studio
Deploying to resource group changes the URL
Need to find out the URL to use as a webhook in service bus event
The webhook looks as follows
If I redeploy without deleting the logicapp it retains the previous URL
But when I delete the logic app and deploy it generates the new URL
Please guide me how to find the URL of the http trigger so that I can bind it to my service bus webhook. Or is there any way to retain the previous url even if I delete and deploy the logicapp .
I am doing the delete/deploy/reploy operations in my dev/sit/qas environment , as I am new to logic App so am not sure what step I am missing and if some understanding issue i have.
Or is there any way to retain the previous url even if I delete and deploy the logicapp .
No, it's impossibble.
When you delete the logic app then deploy or deploy to new resource group, it will create a new logic app. So it will generate a new url.
After you create the endpoint, you can trigger the logic app by sending an HTTPS POST request to the endpoint's full URL. Logic apps have built-in support for direct-access endpoints. Please refer to this article.
I have an Azure App Service set up to deploy from a local git branch. (per instruction from this article). I would like these deployments to trigger another webhook I have set up that posts deploy logs to slack, but I don't see any way to configure a push option in the Azure UI.
Any tips or ideas on how to accomplish this?
You can use Azure Functions to do that.
Here's an Official Azure Documentation article that will help you to work with HTTP triggers and output bindings in Azure Functions
If this solves your problem, do not forget to click on Mark as Answer
In my current company we use GitHub Enterprise as revision control. Where I sign in with SAML to access my account. Now I want to deploy code that is there in GitHub to my Azure App service. So in azure deployment options, I selected GitHub option. But it is saying "Azure needs your permission to access your GitHub account" and asking me to login into GitHub. But I do not have GitHub user name and password as we are using SAML to access GitHub account. Could you please help me how can I authorize GitHub account with Azure?
Azure GitHub deployment process
The Azure deployment process is kinda tricky, trying to deploy from Github Enterprise, I manage to get it working like this:
In the Azure project menu, click on Properties then for the DEPLOYMENT TRIGGER URL, copy it.
Go to the project settings in Github Enterprise, on the option Hooks & Services and add a new webhook, set the DEPLOYMENT TRIGGER URL on the Payload URL, leave everything else the same.
Now we add the deployment process, in the Azure project menu click on Deployment Options then choose as source External Repository
On your Github Account go to settings, then on the menu click on Personal Access Tokens, now generate a new token and give it the following scopes: repo and admin:pre_receive_hook then copy the token
Finally, set the main branch that will activate the webhook when you push code on the repo, on the repository URL we have to set the following items:
https://<github_access_token>:x-oauth-basic#github.<enterprise>.net/<repo_name_from_root>
something like this:
https://c4207e6aae44ce086595c9abfcccb5123caf20cc:x-oauth-basic#github.mycompany.net/repolocation/deployrepo
Now push on your repo and the webhook will automatically trigger the deployment and build process.
What I want to accomplish:
I want to deploy an Azure Cloud Service via Release Management. I managed to get this working by following the steps outlined in this post. In the post the Azure publishsettings file is added to the project and used in Release Management to deploy the Azure package to a Cloud Service. So far so good.
What is the issue:
The Azure publishsettings file will also contain information about the production environment. I don't want that information to be available to all the developers and therefor I would like to have a more secure alternative.
What did I try:
I created a custom action which takes 3 arguments: subscription id, subscription name and certificate key. This way the Azure information stays in Release Management and can be passed to a script. This didn't work because the action is not shown in the Release Template Toolbox.
What is my question:
What is the best way to pass Azure credentials to a deployment script via Release Management on a secure manner?
We have a solution for Build today that will work for RM in the future.
Publish Settings file is an important one with which anybody can get access to certain activities. And once how ever the way you pass on the publish settings file, it can be misused (if tried).
So along with the publish settings file, you need to add a bit of process to the deployment like -
Inactive or remove the management certificate which will in turn invalidate the given publish settings and anyone should request for a new set of publish settings file before they actually start any release procedures.
Even though it adds a rough edge to your smooth flow of deployment process, as it is a live or production system, it is always better to tight the process and make it idiot proof.