i am using azure-pipelines to create a build of my react app and then to deploy it to azure app-service now when i build the app all the required contents go it "/build" folder which then i archive and publish to build artifacts with the corresponding tasks. but the issue is in the archive the structure is "/build/{required files}" but i need the structure as "/{required files}" is there any way to achieve it on azure-pipelines.
i have already looked in azure documentation there they show a variable named "includeRootFolder" but even in the link it does not have a description and in the Archive task i am not able to see any option which will set this variable to false.
There is an option "Prepend root folder name to archive paths" on the task "Archive files" and is enabled per default which causes the behaviour you encounter. Just uncheck this option and this should fix your structure
Related
This is a TFVC repo in Azure, not Git. It is running in Azure DevOps Services, not local in Azure DevOps Server (2019). This is a classic pipeline, not YAML.
I got as far as adding a variable that contains the Label value I am looking to package into the zip file.
I can't figure out how to get the sources by Label value. In the Pipeline Get Sources step, I've narrowed the path down, but then I need to recursively get source files that have the Label in the variable I defined.
The next step is to zip those source files up, I've added an Archive task to which I will change the root folder from "build binaries" to the sources folder.
This is necessary for this particular project because we must pass the source files to the vendor as a zip for them to compile and install for us. The developers create/update the source files, build and test them locally, then apply a Label to the sources for a given push to the vendor.
When configuring 'Get sources' step, there is no any option or method that can only map the source files with the specified label.
As a workaround, in the pipeline job, you can try to add the steps to filter out the source files with the specified label, and use the Copy Files task to copy these files to a folder, then use the Archive Files task in this folder.
[UPDATE]
Normally, a pipeline run will automatically check out the file version (changeset) that triggers the run. If manually trigger the the pipeline, by default the run will check out the latest changeset if you do not specify one.
The labels are used to mark a version of a files or folders, so you also can get the specific version of files or folders via the labels.
In your case, you can try using the 'tf get' command to download the files with the specified labels.
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.
I am attempting to set up a DevOps build definition to build a VS2017 solution on an on-site agent.
After adding the standard Visual Studio Build step to the build pipeline, the build agent reports the error:
"Error MSB3030: Could not copy the file "d:\agent_work..."
This seems to be happening for any LINKED item.
These items were added to the project from other solutions ("add existing item->Add As Link")
The solution/project builds fine locally on developers PCs, but not on agent.
All that is really required is for the build step to copy these files to an output directory to be included in the build artifacts.
Properties for all linked items are set to "content & copy always".
Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found.
Am I missing something basic here?
This is a workspace mapping issue. You have files that aren't part of your build workspace. You will need to update your build to have a workspace that is mapped in a fashion equivalent to your developers' workspaces.
If your developers are referencing files outside their workspaces, this is a problem that you will have to rectify, then update the build accordingly.
Solved the build error : "Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found." by adjusting the mappings in preceding "get sources" step. After looking at the logs of the build it appeared that the agent was looking in "d:\agent" for some items and "d:\agent\s" for other items (and not finding them). Don't know why it was looking in the "s" sub-directoy. But anyway, the work-around was to include the "s" in the local path mappings for "Local path under $(build.sourcesDirectory)" (ie: s/MyLocalPath)
I'm following a learning course on plural-sight and he shows an artifact with cfg folder and json file within that folder(outside of the packge.zip file) but I cant figure out how he managed to configure his build process to get that file there.
How do I achieve this and where should i go to learn more about package files how they are made?
Everything in the "drop" folder gets included in the default "Publish Build Artifacts" Task, just add your files in the drop folder (or subfolders there).
The variable with the path is called: $(Build.ArtifactStagingDirectory)
This images shows a newly created "Publish Build Artifacts" task:
Something similar is probably creating your artifact, check for it in your build definition.
We have a couple of cloud services and do a Continuous Delivery to a test environment via Team Build.
For the production environment, we have our own deployment powershell script. This script needs a .cspkg file for deployment.
My problem is now that I haven't found a way to let team build just create a .cspkg file but not to publish it to Azure.
I've used the AzureContinousDeployment.11.xaml template and it insists on publishing the package.
I've tried to set the "Deployment Settings Name" to an empty string. The build runs without errors, but that way, no package is created.
Is there a way to stop it somewhere in between?
Maybe something I could change in the .azurePubxml file to achieve that?
Environment: VS2012, Team Foundation Service (visualstudio.com)...
On the Process tab of the edit definition:
If you clear out the Deployment Settings Name and all the values under Publishing - Azure Cloud Service and Publishing - Azure Website (except you can leave True for the Allow Upgrade) the building template won't know where to publish the project.
Also on the Build Defaults tab of the edit definition:
Select the "Copy build output to the following Source Control folder (this folder will be created if it does not exist):"
Add some name and path like: "$/your cloud service/drops"
That will cause all your builds to be moved to the drops folder after a successful build. In those drops folders, there will be a app.publish directory that will have your *.cspkg and *csfg files.
I have my custom build template xaml invoke the MSBuild task (Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild) on the Azure project (.ccproj file) with the "Publish" target.
(Despite having the same name as the UI command that pushes the package to Azure, the "Publish" target just means "generate the package without pushing it anywhere".)