Is it possible to trigger an VSTS/TFS build based on the condition if a blob in a storage account is updated?
I tried to create a function app, but with little to no result, I cannot trigger a VSTS/TFS build.
Easiest solution (from my understanding) will be to use a logic app:
Create a logic app that is triggered whenever a blob is added/updated into a specific container.
Queue a VSTS build
NOTE
your VSTS account should have "Third-party application access via OAuth" enabled. (Go to Administration > Control panel > Settings page)
According to the official docs, it is possible to:
...start a function when a new or updated blob is detected. The blob contents are provided as input to the function.
Then, the only thing the Azure function should do it to queue a build in VSTS with the help of REST API. You might also want to check the Getting Started page of VSTS REST API docs - it contains the basic samples to quickly get up to speed.
Related
I want to create a web app with node.js where users can schedule tasks that are executed on a specific time entered by the user.
I was thinking to use azure-webjobs or azure-functions for executing said tasks. I understand that scheduling in the azure portal is possible, however I couldn't find an API to schedule a webjob or function programmatically (for example using the Azure REST API).
Is it possible to schedule a azure-webjob or azure-function programmatically?
Azure WebJobs provide a more or less hidden API inside of KUDU called WebJobs API. This API is REST based webservice and it can be used to manage your jobs programmatically.
There are API endpoints available for the Azure WebJob which will be used for triggering the WebJob.
See the following documentation link for details on the list of available endpoints: https://github.com/projectkudu/kudu/wiki/WebJobs-API
Check this article: How to manage Azure WebJobs programmatically?
Also see this article might be helpful.
I don't know where else to ask this question so would appreciate any help or feedback. I've been reading the SDK documentation for azure machine learning service (in particular azureml.core). There's a class called Pipeline that has methdods validate() and publish(). Here are the docs for this:
https://learn.microsoft.com/en-us/python/api/azureml-pipeline-core/azureml.pipeline.core.pipeline.pipeline?view=azure-ml-py
When I call validate(), everything validates and I call publish but it seems to only create an API endpoint in the workspace, it doesn't register my pipeline under Pipelines and there's obviously nothing in the designer.
My question: I want to publish my pipeline so I just have to launch from the workspace with one click. I've built it already using the SDK (Python code). I don't want to work with an API. Is there any way to do this or would I have to rebuild the entire pipeline using the designer (drag and drop)?
Totally empathize with your confusion. Our team has been working with Azure ML pipelines for quite some time but PublishedPipelines still confused me initially because:
what the SDK calls a PublishedPipeline is called as a Pipeline Endpoint in the Studio UI, and
it is semi-related to Dataset and Model's .register() method, but fundamentally different.
TL;DR: all Pipeline.publish() does is create an endpoint that you can use to:
schedule and version Pipelines, and
re-run the pipeline from other services via a REST API call (e.g. via Azure Data Factory).
You can see PublishedPipelines in the Studio UI in two places:
Pipelines page :: Pipeline Endpoints tab
Endpoints page :: Pipeline Endpoints tab
I hope someone is able to guide me in the right direction.
I am trying to implement the following:
Event Grid -> Function App -> Storage Account
I am also trying to implement the above through ARM templates and Azure DevOps deployment, but I am a bit confused on how to add the Event Grid Bindings to my Function App (.Net) code Files in Azure Repos.
I know in the documentation it says that i need to install the Microsoft.Azure.WebJobs.Extensions.EventGrid" NuGet package, but how is this done through Azure DevOps?
Currently my Release Pipelines are set up as follows:
1) Deploy Function App, Storage Account, Event Grid
2) Deploy Function App Code
3) Get Master Key of function app
4) Create Event Grid Subscription.
Tasks 1-3 execute correctly, but (4) fails with "URL endpoint validation failed" - which im guessing is because I havent installed Microsoft.Azure.WebJobs.Extensions.EventGrid packages correctly in my functions files in Azure repos.
When i set everything up manually and install the Event Grid trigger in the portal, I can easily create the Event Grid Subscription without issues.
How do I 'install' Event Grid Trigger NuGet Packages in Azure DevOps if my Function App code is in Azure Repos?
Much Appreciated.
I know in the documentation it says that i need to install the
Microsoft.Azure.WebJobs.Extensions.EventGrid" NuGet package, but how
is this done through Azure DevOps?
Just as answered in this thread, you need to add a dotnet restore task to restore the package and a .NET Core build task to build the extensions project before archive files.
Besides, we can install and use Event Grid Subscription Extension to create and modify event grid subscriptions in Azure DevOps pipeline.
Below blogs for your reference, hope that helps :
Automatic Subscription of Azure Functions to Event Grid
ARM Template for Event Grid integration with a new Azure
Function
I'm trying to find any way to publish my console app (.net) written for azure data factory v2.
But could not find any solution.
More details would be really appreciated but if you mean that you are using the .NET SDK to create ADF V2 objects, my understanding is that there is no such thing as publish compared to the new User Interface in the portal where you create/edit the objects first and then you click on publish.
if you use the library they get automatically uploaded to ADF V2 and you can easily test that now with the new UI.
It would be useful to have a bit more info on your context. You're talking about running a custom activity from an Azure Batch account? What did you try already?
When running a custom activity, you'll have to upload your executable + depedencies to an Azure storage account. Create a blob container and copy the files there. Then you'll have to configure the activity to use this storage account and the point it to the right container.
If you're asking for a deployment like a right-click -> deploy option, it doesn't exist. I've automated my deployments using PowerShell, using Set-AzureStorageBlobContent to write the files to the Storage account.
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.