We've recently downloaded and are hosting an on-premises Visual Studio Team Services build agent for our source code and have noticed that it's doing an extra step in the build process compared to our hosted agent. This extra step is the 'Post Job Cleanup' as seen below:
When setting up this agent locally there was no options for setting this, and looking at our build steps this extra job isn't listed there:
I've checked online guides but there's been no hint as to where this extra step is coming from. Does anyone know where the option is to include/exclude this for builds is?
Setting process.clean to false in the variables of the release pipeline stops the "finalize job" step from killing all processes.
Setting variables in the release pipeline
https://developercommunity.visualstudio.com/solutions/498153/view.html
Gradle Daemon being killed in "Finalize Job" step
They are the built-in steps and there isn’t the way to remove them (Get source, Post Job Cleanup) in VSTS, you don’t need to worry it, it won’t affect your project or build.
Related
I haven't done any cshtml front-end development for a few years.
What's the current, generally accepted way for ASP.NET Core front-end developers to work across a range of tools on Windows?
By that, I mean a way to have the front-end JS build and the .NET project(s) also build and to work rapidly in the browser and code.
My thinking is.
We have much better command line story around dotnet today.
Some folk like VS Code.
Some folk prefer VS 2019, and some like either, depending.
We need to work on UI aspects sometimes.
But we also need to attach a debugger and debug the server logic sometimes.
The build server should have no problem, be simple, and rely mostly on build logic held in the repo.
Tooling, and kicking off the whole build and serve process should be understandable and familiar.
It should be pretty simple to get going after a team noob clones the repo.
My initial thought would be to setup NPM then use something like Gulp to kick off everything, including running dotnet run.
Then when running under the Visual Studio 2019 debugger, use the Task Runner Explorer to kick off the Gulp stuff but skip the dotnet run part.
(shame there doesn't seem to be a command line for start VS(Code or 2019) and attach debugger)
Now I'm expecting to get a "primarily opinion based" SO beating, but there are general trends and ideas that go into designing all these tools for how they can all play ball together and what the dev story looks like.
You've pretty much already described the process. However, I'll add a few things:
You don't need the dotnet run bit. Visual Studio and VS Code are both capable of debugging directly.
You can assign the gulp tasks to build tasks in Task Runner Explorer, so you really don't even then to think about running those directly. I'm not as sure on this aspect of VS Code, but I'm sure there's probably some extension to handle it, if it's not already built-in.
If you want true ease of development, the best thing you can do is use Docker. Just add a Dockerfile to each project that actually runs (i.e. not a class library) and set up the steps to build and run it there. In Visual Studio, you can right-click the project and choose Add > Docker Support, and it will actually generate a ready-made Dockerfile, though you may need to add a step or two to handle the client-side build steps. In any case, this then becomes truly click and run, with nothing to worry about. The story is even better when you use docker-compose, as then Visual Studio and VS Code can spin up your entire application stack all at once, including external dependencies such as a database, Redis instance, etc. If you haven't used Docker before, start now. It's absolutely revolutionary for development.
One note for CI/CD, as much as possible, you should add a YAML file to describe your CI/CD pipeline. Depending on the the actual provider you're using for build/release, there might be some differences, so consult the relevant documentation. (Azure DevOps, for example, doesn't currently support describing release pipelines in yaml, though you can still do your build that way.) In any case, this allows you to configure all this in code, and have it committed to source control.
You may consider the same for your infrastructure. Azure has ARM templates, AWS has CloudFormation, GCP has Deployment Manager. There's also third-party tools like Terraform or Ansible. All of these, in some form or fashion (usually JSON or YAML) allow you to define all the characteristics of the infrastructure you're going to deploy to and commit that to source control. This makes deployment and things like creating new environments as breeze.
When I queue manually a new build in Visual Studio Online, I start to receive a pop up with the following message :
"There are issues with the request or definition that may prevent the build from running:
There are agents that are capable of running the build, but they are not online. If the agent is configured to run as a service, ensure that the "VSO Agent ({agent name})" service is running.
Queue the build anyway?"
If I say yes, I receive this error :
"
The working folder C:\a\aea16038...\Homebanking PT is already in use by the workspace ws_aea16038_1;Project Collection Build Service on computer TASKAGENT-0001.
The working folder C:\a\aea16038...\Homebanking PT is already in use by the workspace ws_aea16038_1;Project Collection Build Service on computer TASKAGENT-0001.
"
I would like to add, that the builds was working fine and suddenly I start to have issue.
This is a known error. What happened was that the team added a check if your Agent is online before queueing a build. However, in Visual Studio Online your Agent is always offline. After the build is queued the system launches an Agent for you.
This means that you can just hit OK and ignore the warning. The build will then eventually start after an Agent has launched.
The workspace error can most of the time be fixed by queueing a new build and just ignoring the error. You can also play with the option to clean the workspace.
This bug will be fixed in one of the coming Sprints.
I had the same issue running the build agent as a service - in fact the agent is marked red in the pool when I can see it running on our domain server.
In my case I think it must be a firewall issue but without knowing where/how the agent status is determined it is had to add an exception for this. My builds start and hang as a result.
We have a problem with the TFS build agent intermittently hanging while building our solution. We have some custom build actions, we're using eazfuscator, and we have some post build actions as well.
So it's quite possible we are causing the problem. We've identified that the solution (filled with C# projects) starts compiling but does not finish. What we need is the log file from MSBuild/csc, but because the solution never finishes, those logs never go to the build drop.
I need help finding the log file on the build agent. Any ideas?
Thanks!!
I suggest you to copy the MSBuild command which is generated in TFS build for code compilation, run the same command on build agent server manually from command prompt. Here, you will get more details to figure out the cause build for hanging issue.
I'm trying to create a CI process for SQL Server Reporting Services.
I am fairly new to TFS but quite experienced with MSBuild. In the past I've used a combination of MSBuild with Team City so the whole build process is more or less custom.
Here lies the start of my problems, as the solution I am deploying only contains Report Server projects (rds), no compilation is required. I thought that I would override the the first default task that TFS runs (EndToEndIteration) to override the default TFS build sequence and inject my own.
The first snag that I have come across is that the build always fails, how can I set the status of the build to success? Currently the EndToEndIteration task is very light and only has a message.
Is this the best method to create a custom build process in TFS where compilation is not required? Or should I use the default sequence and override one of the hook tasks mentioned in
http://msdn.microsoft.com/en-us/library/aa337604%28VS.80%29.aspx
(ie: AfterCompile)
The core steps that I'd like to achieve are:
Bundle the RDL and datasource files
Connect to the host server to
register/deploy the reports
Re-apply any subscriptions that
previously existed
Run tests to verify the deployment
succeeded and is returning results
as expected
I have found another article on Report services deployment:
Reporting Services Deployment
But it doesn't mention the best practice for customizing the standard build process.
Any help would be appreciated.
For anyone interested I've just stumbled apon an answer to the first question I asked:
The first snag that I have come across is that the build always fails, how can I set the status of the build to success?
You can find a solution to this at
Link
The options available for this property are:
Unknown
Failed
Succeeded
Don't forget to also set the TestStatus else the build will only partially succeed
Still looking for the best practice for creating a custom build sequence.
I ask this question because I find the the community contributions to the various build engines (like MSBuild and NAnt) do include all the tasks that promote for CI servers, like getting versions from source control, cleaning folders, changing build numbers, sending emails, etc...
Is it only because it "listens" to the changes happens on the source control repository? what else am I missing?
Grzegorz Oledzki linked a good resource for finding the differences between multiple CI solutions, but it should be noted that the intent of MSBuild is to specifically turn code into binary and is used by CI software to build the source. It's true that it can do other things but most of its tasks lie closely within that realm.
In addition to what you mentioned about listening to the repo, some CI servers can do all kinds of things like^1:
multi-agent building (not just multi-core, msbuild can do that, but multi-machine)
monitoring build status
notifications (e-mail/sms/rss/whatnot)
assigning blame for broken builds
administrative features
supporting XFDs (extreme feedback devices)
automated deployment
And generally all from a handy UI.
1 Not all CI software will have all of these features, it is by no means meant to be exhaustive and there is some overlap.
I believe CI (Continuous Integration) feature matrix will answer all your questions about particular CI providers and their capabilities.
Wow there are just so many answers to this. As for what a CI system can do that a Build Script can't do other than listen to your Version Control System... Well for starters systems like TeamCity can let you first test your code on the build server and then check it in if it passes all the tests for starters.
I highly recommend using a CI server but I prefer to keep all of the build logic in a MSBuild file and all of the who to notify when it fails etc. in the CI server. Keeping the logic in the Build file helps you to reproduce the build on your own machine and makes it simple to set up new projects in the CI server or to change how the CI server builds the project