I have a release pipeline in TFS 2017, which runs on Linux agent and has Docker and PowerShell tasks. However Docker tasks are working fine but PowerShell tasks are failing because there is no .Net Framework installed.
What is the way to run PowerShell task on Linux agent or how to install .Net Framework on Linux agent?
TFS 2017 predates support for PowerShell Core, which is cross-platform and runs on Linux. So the built-in PowerShell task is going to be useless for this scenario.
However, you can still run a PowerShell script on your Linux agent, you'll just have to use a Command Line task to call pwsh. Naturally, you'll have to ensure that PowerShell Core is installed on your Linux agent.
Upgrading to a more recent version of TFS will also include an updated PowerShell task that includes a checkbox for "Use PowerShell Core", which will also solve the problem.
Related
I am using TFS 2017 and recently added RHEL Linux build agent with docker installed on it, but when I am trying to queue docker based build on this agent I am getting below error
Issues with deploy phase 'Run on agent' - No agents could be found that match the following demands (queue: 'DockerLinuxRHEL'): DotNetFramework
I have also tried removing it from build definition, but it's greyed out.
Is there a way to remove this default demand because this agent is just for docker stuff I don't want to install anything else?
It because you have a task that required .Net framework installed, like PowerShell, MSBuild, etc.
When you will remove the task the demand will be removed.
How to remove default demand DotNetFramework from TFS agent?
I am afraid we could not remove the default demand DotNetFramework.
Just like Shayki said the demand comes from the powershell task itself. So, if we want use the powershell task, we have to install the Net Framework on Linux machine.
However, it's not recommended to build .net framework projects in Linux environment. Usually we use mono with reference assemblies and the dotnet cli to do that.
More details please refer to this blog and the discussion here.
So, remove default demand DotNetFramework or install Net Framework on Linux machine is not a viable option.
To resolve this issue, we could use the PowerShell Core task:
- pwsh: # inline script
workingDirectory: #
displayName: #
failOnStderr: #
errorActionPreference: #
ignoreLASTEXITCODE: #
env: # mapping of environment variables to add
Note: pwsh runs PowerShell Core, which must be installed on the agent or container.
Hope this helps.
The TFS2017 supports build agents only on a 64bit OS and TFS2017 does not support the (32bit-)agents from TFS2015 anymore.
However, we need to run our test code on our 32bit OS to stay as similar to the production environment as possible. :/
We consider using Jenkins as a TFS triggered agent to execute the build and run the NUnit test steps on the 32bit OS, but it sounds like a high administrative load.
Does anyone have experiences to circumvent the missing 32bit TFS agent? Or do you see any other possiblitiy?
You could build your project on build agent server and run test on test agents server. Test agent could be install on both 64 and 32 bit system. Make sure the build agent and test agent are connecting.
Create a build definition all these steps:
Nuget Restore
Build solution
Copy Files (Copy to $(build.artifactstagingdirectory))
Publish Artifacts to a share folder or Server
Visual Studio Test Agent Deploy: Deploy the test agents to your 32 bit server.
Run Functional tests: The Test Drop location is where you publish your code to.
For more details: https://www.visualstudio.com/en-us/docs/test/continuous-testing/set-up-continuous-testing-builds
Note:
If the test agent can't be deploy successfully, you could install it manually. Download from here. Remember to restart the server after install test agent.
I have my Mac setup with Jenkins and SonarQube and Docker to test automation. I also have the same setup on my Windows VM using VMWare and all the windows variants as well. My .NET application compiles well and I can run SonarQube after pulling from GitHub and running MSBuild.exe against it fine. But how can I do a similar process with the 'dotnet restore', 'dotnet publish' on my Mac with the .NET Open Source projects like ASPNET Core 1.1? I have not seen how to setup SonarQube to scan the ASPNET Core 1.1 or the DotNet Core 1.1 projects with any prebuild, build, postbuild steps from within Jenkins. Is there support for the ASPNET Core yet in SonarQube? Do I need a patch or to run a certain commandline group of scripts to do the same thing natively on my Mac? Any help is appreciated. I have searched for a few hours and have found nothing.
The support of .NET Core projects is not yet available in the SonarQube Scanner for MSBuild. We are currently working on it and it should be available within the upcoming 2 weeks.
Feel free to watch SONARMSBRU-167 to follow the status.
I have been assigned a task to do build automation using jenkins which should perform checkout, compile & build automatically.
Existing set up - Currently we have PVCS installed in one of our AIX server where build process(checkout,compile,build) is automated using ant script.
I have installed jenkins in my windows server.
How do i get the code into my windows server from PVCS which resides in AIX server to perform build through jenkins.
Thanks in advance.
As I posted on CodeRanch where you posted the same question, you need to install the PVCS plugin for Jenkins.
On my local dev machine this works perfectly:
msbuild project.name.csproj /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
I'm trying to configure a Build step in TeamCity with MSBuild, in the "Command line parameters" I'm putting this:
/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
It runs, no errors are displayed, but files are not copied to "c:\proyectos\folder1\deploy"
Edit: I'm having the same issues with MSBuild on the command prompt, so it's not teamcity. My local dev machine is on windows 7 and the server is windows 2003
Run with /v:d or v:diag to get logging.
(Get it working local first but... In TeamCity, view the agent in the console and look at the agent detail logs for similar such logs (or just pass the same /v: flag to MSBuild via TeamCity))
You'll want to ensure that the user running the "TeamCity Build Agent Service" has write access to the relevant directories.
(FWIW, I believe the LocalSystem account has different group memberships in Server 2003 and Windows 7. We run all of our TeamCity build agents under their own "teamcity" accounts to more explicitly control permissions and allow access to network shares.)
Installing Visual Studio 2010 DOES fix this problem. But, you can also fix it by copying the appropriate build targets to your machine. Typically, on your dev machine they'll be at (Or take away the (x86) for 32 bit machines):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
In there you'll find a bunch of Microsoft.Web.Publishing.* targets.
Just copy those over to the equivalent location on your build machine and all will be well.
Installing Web deploy tool through web platform in the server works for me. Actually visual studio installation installs web deploy, It might be the reason why it works for #himinaya.