Long story short, I was able to build a bitbucket .NET/MVC/Angular project successfully on windows 2019 azure hosted agent, but I am unable to make it build successfully on ubuntu agent.
The reason I want to build it on ubuntu is because I noticed the build time is way faster than that of the windows agent, which makes sense considering the platforms.
I am facing this error:
Copying file from "/home/vsts/work/1/s/Bobby.ProjectA/obj/Debug/Bobby.ProjectA.pdb" to "/home/vsts/work/1/s/Bobby.ProjectA/bin/Bobby.ProjectA.pdb".
CopyRoslynCompilerFilesToOutputDirectory:
Creating directory "/bin/roslyn".
Creating directory "/bin/roslyn".
Creating directory "/bin/roslyn".
Creating directory "/bin/roslyn".
/home/vsts/work/1/s/packages/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8/build/net45/Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props(17,5):
warning MSB3021: Unable to copy file "/home/vsts/work/1/s/packages/Microsoft.Net.Compilers.2.4.0/build/../tools/csc.exe" to "/bin/roslyn/csc.exe". Access to the path '/bin/roslyn' is denied. [/home/vsts/work/1/s/Bobby.ProjectA/Bobby.ProjectA.csproj]
According to this post, the issue is because the VBCSCompiler is locking the src.
So i have exhausted all of these solutions here to kill the VBCCompiler, but none of them worked.
I also can't restart the ubuntu agent during a build due to CI limitation, and killall VBCSCompiler bash script before msbuild task resulted in this error: VBCSCompiler: no process found
So now i am stumped, if VBCSCompiler process is not even running, why is Access to the path '/bin/roslyn' denied???
Ive also tried updating/installing Microsoft.CodeDom.Providers.DotNetCompilerPlatform package per this post here, but that didnt do/help anything.
This is how my build tasks looks like if it helps:
Related
I am running a local Microsoft DevOps server along with two separate machines running test agents for nightly automated testing. I recently configured a third test agent, but have run into issues with it publishing artifacts during the Build jobs to be used by the Release jobs.
The same jobs run perfectly on the two existing test boxes, but always throw this error after the build has completed and during the artifact publishing step:
2020-09-01T21:32:29.2544245Z ##[section]Starting: Publish Artifact:
bin_drop 2020-09-01T21:32:29.2548130Z
============================================================================== 2020-09-01T21:32:29.2548196Z Task : Copy and Publish Build
Artifacts 2020-09-01T21:32:29.2548235Z Description : [DEPRECATED] Use
the Copy Files task and the Publish Build Artifacts task instead
2020-09-01T21:32:29.2548273Z Version : 1.0.32
2020-09-01T21:32:29.2548311Z Author : Microsoft Corporation
2020-09-01T21:32:29.2548365Z Help : More
Information
2020-09-01T21:32:29.2548404Z
============================================================================== 2020-09-01T21:32:30.7956739Z ***.runsettings
2020-09-01T21:32:30.8306609Z ##[error]Cannot publish artifacts from
OSX or Linux to a file share. You can change 'Artifact Type' to
'Server', use Windows, or use the 'Copy Files', 'Copy Files Over SSH',
or 'FTP Upload' task. 2020-09-01T21:32:30.8378696Z
##[section]Finishing: Publish Artifact: bin_drop
In attempting to solve this issue I did look into using the Publish Build Artifacts task instead, but its description says it would have the same problem (e.g. doesn't work on Linux etc.). To be clear, the newest test box is the same as the other two running windows 10, it is NOT running linux or OSX.
In looking at Microsoft's test agent code (I think I found the correct GitHub package here), it looks like they are using Node.js to detect the platform the agent is running on, and if it does not equal 'win32', then they are throwing this error.
So I navigated to the Node.js instance inside the agent:
\agent\externals\node\bin
\agent\externals\node10\bin
and ran this code, and verified that it did indeed return 'win32' from both Node.js instances:
const os = require('os');
console.log(os.platform());
As near as I can tell the configuration on the third box is the same as the other two Windows 10 test boxes. And this should not be throwing this error. Does anyone have an idea why the test agent might be getting a value other than 'win32' so it thinks it is not running on windows and throwing this error for me?
EDIT:
I did try removing and re-configuring the agent on the machine. On all the text boxes the agent is running in interactive mode so it can run GUI tests.
Also, I recently had to rebuild one of the other two test boxes (after I was already struggling with box 3), and that rebuild went fine. A complete re-install of everything and it is working perfectly just like it was before.
I was able to solve this issue by copying the agent from a working test machine. It seems as though the more recent agent downloaded from the DevOps server itself has a bug in it.
Copying the agent from a working machine and stripping all the _work and configuration data from it, then installing it on the new third test machine resulted in a working machine.
The test machine I rebuilt while struggling with machine three was successful because I did not do a full reformat. Just reinstalled the OS, then used the install files from its data drive to finish installing the required software on it, so I never had to download a new agent for it from the DevOps server.
For a very long time the following command worked as expected:
msbuild /property:Configuration=Release /property:TransformConfigFiles=true /property:DeployOnBuild=true /property:PublishProfile=FolderProfile /verbosity:normal /target:Rebuild /fileLogger /nologo /m Ticket.Corporativo.sln
By "expected" I mean, the project is built, then "packaged" into a "pkg" folder according to a publish profile called "FolderProfile" which is a simple file system deployment.
The last time it worked as expected was 2019-01-30. On the daily build of the 31st, the 'pkg' folder of "FolderProfile" was no longer created. Checking the build server, nothing we could track was changed... no updates, no nothing!
I've run out of ideas or items to check that could explain this failure... can anyone help?
PS:
-MSBuild version is 14.0
-Project being built
-Works on local machine as expected
I figured it out: Apparently, on my local machine, I added a reference to a package that was not available in our internal NUGET (only available on the public NUGET), which is the only source the builder machine has access... that caused an error, but was not reported as such, it failed silently... after copying the nuget pack to out server, it worked again perfectly
I am trying to build IAR Embedded workbench code using VSTS batch script. The .bat file is located in TVFC repository hosted by Microsoft.
C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\common\bin\IarBuild.exe" "C:\embedded_programming\lesson2\project.ewp" -build Debug -log all
The builds terminates with an error "The system cannot find the path specified" as shown in linked image:
It don't know what I am doing wrong since I am new to VSTS but it works fine with Command Line Interface.
Please help!
Thanks a lot :)
If you're using the hosted agent, that's the problem. Your software isn't installed on the hosted agent, and there's no way for you to install it since the hosted agent is provided by Microsoft.
You'll need to set up a private agent that runs on a machine that has the appropriate software installed.
I have an automation script that uses maven POM.xml to import all the dependencies needed from selenium and junit. The main test uses selenium to open a browser, verify some information, close the browser and the test ends.
When run as Junit it works fine: run as Junit test
When run as Maven Test it works fine as well: run as maven test
In both scenarios, the program opens the browser and navigates through the website as it should do for an automated test.
Now I need to integrate it to VSTS so I can visualize the overall pass/fail test on the VSTS dashboard but I'm not familiarized with this tool too much yet.
So far this is what I have managed to do:
Deploy an agent on my WindowsPC (I want to execute and deploy the project on an Azure VM or another azure instance later on) NOTE: this is the same pc I'm successfully running the program using eclipse as shown in the screenshoots above. https://learn.microsoft.com/en-us/vsts/build-release/actions/agents/v2-windows?view=vsts
Create a build definition on VSTS but when I queue the definition the build fails: build definition and the build fail.
I don't know why it can't find mt config.txt file since it is located on the same hosted agent in that same directory. I'll appreciate if someone is capable of guiding me through this process so I can run the program from the VSTS and visualize the overall tests that fail and pass on the VSTS dashboard.
UPDATE: I moved the config.txt file to the public directory and the build was successful(I still need to fix this issue because I do not want my work in a public folder).
Now the problem I have is that even though the build is successful and it looks like it is running my "3 tests", When I look at my pc, nothing is happening. it should open chrome and take a screenshot, then open Firefox and take another screenshot and finally open internet explorer and take another screenshot and save each test on different folders but it is only generating folders for chrome and internet explorer (but still those folders does not have the screenshot I'm asking, maybe because the browser is not being open on the computer.)
Here is the log: https://drive.google.com/open?id=1S_MhAUmzj8i9phPQiqS06s0_1cCRrbF0
test output report generated on my computer
test output on vsts
Look at the error message. The error message tells you precisely what the problem is: java.io.FileNotFoundException: Y:\Automation Team\CopaQA\Architecture\local\config.txt (The system cannot find the path specified)
You need to not rely on hard-coded paths.
You say you registered a build agent against your VSTS account... but did you change the agent queue for your build? If the agent queue is "Hosted", you're using Microsoft's hosted agent.
I don't know why it can't find mt config.txt file since it is located on the same hosted agent in that same directory.
It turns out that Java.IO. can't read files located on a shared network drive, I solved this by using the UNC path to that file (//"computername"/"directory"/"file.txt")
Now the problem I have is that even though the build is successful and
it looks like it is running my "3 tests", When I look at my pc,
nothing is happening.
It took me a little reading to realize that to perform UI tests my agent needs to be set up in INTERACTIVE MODE. it can be done following this guide: https://learn.microsoft.com/en-us/vsts/build-release/actions/agents/v2-windows?view=vsts
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.