how to deploy artifact of VM desktop? - azure-devops

I tried to copy task extension on azure pipeline: $vmFolder="c:/users/[username]/desktop and also tried
$vmFolder="c:/users/public/desktop but still my artefacts are deployed inside c:/azagent/work/ location. If anyone has an idea, please explain me the process step by step.

Could you provide a little more detail about what you're trying to achieve?
My feeling is that there may be a confussion about what is an Agent (C:\azagent\work is the work directory in a machine where you, very likely, have installed an Agent) and the Machine where you want to deploy your code to run.
Bests.

When you publish the build artifacts in Azure DevOps, for the location you could only choose "Server" or a UNC file share.
Artifact publish location argument:
Azure Pipelines/TFS (TFS 2018 RTM and older: Artifact type: Server)
is the best and simplest choice in most cases. This choice causes the
artifacts to be stored in Azure Pipelines or TFS. But if you're
using a private Windows agent, you've got the option to drop to a
UNC file share.
More details please refer our official doc -- Artifacts in Azure Pipelines
The remaining alternative is to add a download artifacts task in the end of pipeline to download your published artifacts to your Destination directory.

Related

Azure Devops - Release pipeline. How do I share the fileshare to on prem VM

I'm just trying to get my fist Release pipeline underway.
Our current infastrucure setup is that we have a number of On Prem VM's which I have deployed the Azure Agents as per the deployment group setup.
The issue I have at the moment is that the deployment first tries to download the artifact from our build server using a file share.
However, currently the deployment machine cant see the file share. I gather I am supposed to be able to see the file share. I'm not entirely sure how to share this folder on the build machine?
Am I supposed to just create a share for everyone to see? Or is there a particluar user/role that I am having to share it for?
Our current infastrucure setup is that we have a number of On Prem VM's which I have deployed the Azure Agents as per the deployment group setup.
You need to check which user is used to run the tasks on the agent. You can add a powershell task with inline script: whoami.
You need to make sure the account have access to the file share.
In addition, when you publish artifact, you can select file share to store the artifact and then you can consume the artifact in the release pipeline. Please check the link for the details.
My "Download artifacts from file share" in release pipeline screenshot:

Is there an equivalent of GitHib releases in Azure DevOps?

Simply speaking, does Azure Devops have something that works very close to GitHub releases?
I would like to publish artifacts that are created during an Azure DevOps pipeline so that they be easily viewed and downloaded afterwards in a central location. The closest equivalent to what I'm looking for is how GitHub releases work, where there is a web page listing out all the versions of the repository and the assets that can be downloaded for each version.
It seems to me that published artifacts within Azure DevOps pipelines are always tied to the run of the pipeline, and there isn't an easy way to see one list of artifacts that have been created in a historical view like GitHub releases provides, but maybe I'm missing something.
Azure Artifacts does not meet my needs because it is tied to particular packaging formats and is meant to be used for developer tooling.
I would like to publish artifacts that are created during an Azure
DevOps pipeline so that they be easily viewed and downloaded
afterwards in a central location.
As a workaround ,you can switch Artifact publish location to A file share in Publish Pipeline Artifacts task then specify your network drive folder path.
Specifying the path to the file share where you want to copy the files. The path must be a fully-qualified path or a valid path relative to the root directory of your repository. Publishing artifacts from a Linux or macOS agent to a file share is not supported.
Besides, there should be no other built-in hosting, I am afraid that Azure Artifact is the closest to your needs. because it is tied to particular packaging formats you can consider using Universal Packages.

Does TFS has releases tab like we have at GitHub Releases

I am looking for hosting .exe files in Azure Devops. It seems to don't have feature similar to how we host executable or build files in GitHub for other people to download. Do we have such kind of feature to host the executables and have the latest commit tagged?
You can try publishing the executable or build files as Build Artifacts in Azure devops build pipeline.
You can create a pipeline in azure devops and using Publish build artifacts task to store the executable or build files in azure pipeline
See example here to create a classic azure pipeline. See Here for yaml pipeline example.
When you run the pipeline. You will see the commit hash and the files uploaded in the highlighted field of the build summary page shown in below screenshot. And you download the files from there.
You can retain this artifacts by Clicking retain in the pipeline run. See below
You can also change the retention policy for your pipeline. See here for more information.
Go the Project settings page-->Settings under Pipeline. See below:

Download build artifacts from file share does not show drop folder content

At the end of the build, I publish artifacts to a file share drive.
But in the release pipeline, if I select the Agent job, I don't see the content of the drop folder, as shown below. Do I have to use a Download Build Artifacts task to go around this ? Or can I still use this option of the Agent job somehow ?
The artifacts were correctly published to the file share. However I also noticed that I cannot open the artifacts folder from the build log. I only see the path. How come ?
Download build artifacts from file share does not show drop folder content
This is an expected behavior. When we choose publish artifacts to a file share drive instead of Azure pipeline, the share drive can be our local path or a network shared folder.
So this share drive is more controlled by us than azure devops. In this case, Azure devops cannot provide a direct download link, only the path where we store the file.
Do I have to use a Download Build Artifacts task to go around this ?
Or can I still use this option of the Agent job somehow ?
It depends on whether your agent running your release pipeline can access your share drive.
If yes, just like Shayki Abramczyk said, the agent will download the artifacts from the file share at the beginning of release.
Note: You need set the build pipeline as artifact source:
The output:
If the agent could not access that share drive, we need use the task like Download artifacts from file share to download the artifact.
Hope this helps.
This is the behavior of publishing to a file share, you can't "explore" the files inside Azure DevOps if it stored on a file share.
You don't need to use the Download Build Artifacts task because the agent will download the artifacts from the file share at the beginning of his run.

Publishing artifacts to an external server

We are using azure devops pipeline to build our application including a Azure build agent. At the end of this process, I would like to publish the artifacts to an on-premise server shared directory (which will connect to company mandated deployment process (repliweb)).
Is that possible?
Looking at the documentation it looks like I can use publish artifact or copy file step (or maybe even ftp).
Our IT organization needs to know the IP/port so that the firewall rules can be authored.
Where can I get that information?
I suppose the other possibility would be have our server pull the artifact from Azure devops.
Publishing artifacts to an external server
For this issue, you can try to use FTP Upload task in the pipeline. Using this task in a build or release pipeline to upload files to a remote machine using the File Transfer Protocol (FTP), or securely with FTPS.
For details,please refer to this document.