I'm developing a release pipeline where I would like to do some analysis on a given artifact. I will not use the artifact itself for anything later, I'm only interested in reading certain properties such as version number. I, therefore, think that it is unnecessary to download an artifact that I won't do any changes to or to publish. From my point of view, the most time and resource-efficient way would be to not have to download the artifact, but I'm not sure if this is possible. Or are there workarounds, where you can download a "lite" version of the artifact? I'm planning on using a task for this.
If you want to get metadata for your build/pipeline artifact, you can't do this as there is no such thing. You can call this endpoint:
https://dev.azure.com/{{organization}}/{{project}}/_apis/build/builds/6179/artifacts?api-version=6.1-preview.5
but you will only get something like this:
{
"count": 1,
"value": [
{
"id": 1095,
"name": "drop",
"source": "12f1170f-54f2-53f3-20dd-22fc7dff55f9",
"resource": {
"type": "Container",
"data": "#/6799617/drop",
"properties": {
"localpath": "D:\\a\\1\\a",
"artifactsize": "1330651"
},
"url": "https://dev.azure.com/thecodemanual/4fa6b279-3db9-4cb0-aab8-e06c2ad550b2/_apis/build/builds/6179/artifacts?artifactName=drop&api-version=6.1-preview.5",
"downloadUrl": "https://dev.azure.com/thecodemanual/4fa6b279-3db9-4cb0-aab8-e06c2ad550b2/_apis/build/builds/6179/artifacts?artifactName=drop&api-version=6.1-preview.5&%24format=zip"
}
}
]
}
If you want to get details of you package in Azure Artifact, which is a feed, you have some option in REST API. For instance: Artifact Details - Get Package Version
Related
[warning] Via 'product.json#extensionEnabledApiProposals' extension
'github.vscode-pull-request-github' wants API proposal
'commentsResolvedState' but that proposal DOES NOT EXIST. Likely, the
proposal has been finalized (check 'vscode.d.ts') or was abandoned.
I don't know what is this error msgs mean is it a bug on the current version of vscode 1.75.1?
I don't know why it's called extension even though I don't install any extension named github.vscode-pull-request-github
also I tried to (check 'vscode.d.ts') in my laptop. I dont find any file of it, there's only vscode.d. Well My code and project still works find but this error msg always appear every time I opened my vs code and kind of annoying to see. I use windows 11
This is what I found on github:
https://github.com/microsoft/vscode-pull-request-github/pull/4447/commits/f36acaff7b81f077db18e74a7c673cf249eba996
I tried to put the code in setting.json but it seems doesn't work. this is the code:
{
"name": "vscode-pull-request-github",
"displayName": "%displayName%",
"description": "%description%",
"icon": "resources/icons/github_logo.png",
"repository": {
"type": "git",
"url": "https://github.com/Microsoft/vscode-pull-request-github"
},
"bugs": {
"url": "https://github.com/Microsoft/vscode-pull-request-github/issues"
},
"enabledApiProposals": [
"tokenInformation",
"contribShareMenu",
"treeItemCheckbox",
"contribCommentPeekContext",
In Azure DevOps, we can organize our Build/Release definitions into high-level folders:
Example: for every pipeline that resides in the Framework folder, I want to conditionally execute a certain task. The pre-defined Build and Release variables provide a plethora of ways to discover information about the underlying file system, but seemingly nothing for this internal path information.
During a pipeline run, is it possible to determine the folder/path that it resides in?
You can check it with Rest API - Builds - Get:
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}?api-version=6.0
In the response you get the definition details including the path:
"definition": {
"drafts": [
],
"id": 13,
"name": "TestBuild",
"url": "https://dev.azure.com/xxxxx/7fcdafd5-b891-4fe5-b2fe-xxxxxxx/_apis/build/Definitions/13?revision=1075",
"uri": "vstfs:///Build/Definition/13",
"path": "\\Test Folder",
"type": "build",
"queueStatus": "enabled",
"revision": 1075,
"project": {
"id": "7fcdafd5-b891-4fe5-b2fe-9b9axxxxx",
"name": "Sample",
"url": "https://dev.azure.com/xxxx/_apis/projects/7fcdafd5-b891-4fe5-b2fe-9xxxxxx",
"state": "wellFormed",
"revision": 97,
"visibility": "private",
"lastUpdateTime": "2021-03-22T10:25:39.33Z"
}
},
So:
Add a simple PS script that invokes the rest API (with the $(Build. BuildId) pre-defined variable)
Check the value of the path property
If it contains the Framework folder set a new variable with this command:
Write-Host "##vso[task.setvariable variable=isFramework;]true"
Now, in the task add a custom condition:
and(succeeded(), eq(variables['isFramework'], 'true'))
In Azure DevOps, I have created a Task Group that runs Postman tests using the newman CLI. As inputs, users can pass in the paths to the Postman collection and environment files.
As the newman CLI is a requirement, the first task in the Task Group is to install it. However, in scenarios where several collections are run, there is no need to keep installing the CLI over and over, so I would like to offer a checkbox and then conditionally run the install task depending on the value of that checkbox.
As the UI for Task Groups is pretty lacking in useful options, I started exploring the API. I'm able to add additional inputs, but setting the obvious type option to checkbox yields only an additional text (string) input.
POST https://dev.azure.com/{org}/{project}/_apis/distributedtask/taskgroups?api-version=5.1-preview.1
{
...
"inputs": [
{
"aliases": [],
"options": {},
"properties": {},
"name": "Rbt.Cli.Install",
"label": "Install 'newman' CLI?",
"defaultValue": true,
"required": false,
"type": "checkbox",
"helpMarkDown": "Choose whether or not to install the 'newman' CLI. You only need to install it if it hasn't already been installed by a previos task running on this job.",
"groupName": ""
},
...
],
...
}
Looking more closely at the documentation, there is a definition for inputs - TaskInputDefinition. However, it looks as though whoever was tasked with writing that documentation left early one day and never got around to it. There are no descriptions at all, making it impossible to know valid values for properties in the definition.
How can I add a checkbox to my Task Group?
I have now found that Task Groups offer picklist as an input type. This has allowed be to present a yes/no option to the user, and based on their answer I am able to conditionally run a task.
I would still prefer to have a checkbox though, should anyone know how to do that.
{
"aliases": [],
"options": {
"yes": "Yes - install CLI",
"no": "No - the CLI has already been installed"
},
"properties": {},
"name": "Postman.Cli.Install",
"label": "Install 'newman' CLI?",
"defaultValue": "yes",
"required": true,
"type": "picklist",
"helpMarkDown": "Choose whether or not to install the 'newman' CLI. You only need to install it if it hasn't already been installed by a previos task running on this job.",
"groupName": ""
}
You can add checkbox to pipeline task easily by setting the type as boolean
{
"name": "Rbt.Cli.Install",
"type": "boolean",
"label": "Install 'newman' CLI?"
}
And also control the visibility of other controls based on the check box state as following:
{
"name": "someOtherField",
"type": "string",
"label": "Some other field",
"visibleRule": "Rbt.Cli.Install = true"
},
I need a work around pretty quickly - this was a late surprise in the dev process when we added an Az function to our development ADF pipeline.
When you use a function app in ADF V2, when you generate the ARM template, it does not parameterize the key references unlike in other linked services. Ugh!
So for CI/CD scenarios, when we deploy we now have a fixed function app reference. What we'd like to do is the same as other linked services - override the key parameters to point to the correct Dev/UAT /Production environment versions of the functions.
I can think of dirty hacks using powershell to overwrite (does powershell support ADF functions yet? don't know - in January they didn't).
Any other ideas on how to override function app linked service settings?
the key parameters are under typeProperties (assuming the function key is in keyvault):
{"functionAppUrl:="https://xxx.azurewebsites.net"}
{"functionkey":{"store":{"referenceName"="xxxKeyVaultLS"}}}
{"functionkey":{"secretName"="xxxKeyName"}}
Right now these are hard coded from the UI settings - no parameter and no default.
ok, eventually got back to this.
The solution looks a lot but it is pretty simple.
In my devops release, I create a Powershell task after both the data factory ARM template has been deployed and the powershell task for deployment.ps1 with the "predeployment=$false" setting has run (see ADF CI/CD here.)
I have a json file for each environment (dev/uat/prod) in my git repo (I actually use a separate "common" repo to store scripts apart from the ADF git repo and its alias in DevOps is "_Common" - you'll see this below in the -File parameter of the script).
The json file to replace the deployed function linked service is a copy of the function linked service json in ADF and looks like this for DEV:
(scripts/Powershell/dev.json)
{
"name": "FuncLinkedServiceName",
"type": "Microsoft.DataFactory/factories/linkedservices",
"properties": {
"annotations": [],
"type": "AzureFunction",
"typeProperties": {
"functionAppUrl": "https://myDEVfunction.azurewebsites.net",
"functionKey": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "MyKeyvault_LS",
"type": "LinkedServiceReference"
},
"secretName": "MyFunctionKeyInKeyvault"
}
},
"connectVia": {
"referenceName": "MyintegrationRuntime",
"type": "IntegrationRuntimeReference"
}
}
}
...and the PROD file would be like this:
(scripts/Powershell/prod.json)
{
"name": "FuncLinkedServiceName",
"type": "Microsoft.DataFactory/factories/linkedservices",
"properties": {
"annotations": [],
"type": "AzureFunction",
"typeProperties": {
"functionAppUrl": "https://myPRODfunction.azurewebsites.net",
"functionKey": {
"type": "AzureKeyVaultSecret",
"store": {
"referenceName": "MyKeyvault_LS",
"type": "LinkedServiceReference"
},
"secretName": "MyFunctionKeyInKeyvault"
}
},
"connectVia": {
"referenceName": "MyintegrationRuntime",
"type": "IntegrationRuntimeReference"
}
}
}
then in the devops pipeline, I use a Powershell script block that looks like this:
Set-AzureRMDataFactoryV2LinkedService -ResourceGroup "$(varRGName)" -DataFactoryName "$(varAdfName)" -Name "$(varFuncLinkedServiceName)" -File "$(System.DefaultWorkingDirectory)/_Common/Scripts/Powershell/$(varEnvironment).json" -Force
or for Az
Set-AzDataFactoryV2LinkedService -ResourceGroupName "$(varRGName)" -DataFactoryName "$(varAdfName)" -Name "$(varFuncLinkedServiceName)" -DefinitionFile "$(System.DefaultWorkingDirectory)/_Common/Scripts/Powershell/Converter/$(varEnvironment).json" -Force
Note:
the $(varXxx) are defined in my pipeline variables e.g.
varFuncLinkServiceName = FuncLinkedServiceName.
varEnvironment = "DEV", "UAT", "PROD" depending on the target release
Force is used because the Linked service must already exist in the Data Factory ARM deployment and then we need to force the overwrite of just the function linked service.
Hopefully MSFT will release a function app linked service that uses parameters but until then, this has got us moving with the release pipeline.
HTH. Mark.
Update: Added the Az cmdlet version of the AzureRM command and changed to Set ("New-Az..." worked but in the new Az - there is only Set- for V2 linked services).
Short question: How can I make composer require my branch from my fork without checking all tags?
Long question:
I want composer to require a specific branch that I created of a fork I created from twig.
My assumption was, that, when defined correctly, composer directly requires the branch.
Instead first it checks all the tags and after that it loads the branch.
I don't want composer to check the tags, I just want to use the branch.
Is this the correct behaviour or am I requiring the branch incorreclty?
My fork would be github.com/myfork/Twig
My branch would be mybranchname
This is my composer.json
{
"require": {
"twig/twig": "dev-mybranchname"
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/myfork/Twig"
}
]
...
...
This is the correct behavior. Composer checks for all tags first before it could get to your branch name.
You can check if your code is fetched from the right repository by checking your composer.lock
Your composer.lock should be like this.
{
"name": "twig/twig",
"version": "dev-mybranchname",
"source": {
"type": "git",
"url": "https://github.com/myfork/Twig",
"reference": <your_revision_number>
},
...
}