I have couple of developers changes and they are all checked in to source control. Team city build is failing because of one of the developers changes. Since I already ran the build with both developers changes, how do I revert back to what it was originally (before two changes state)..what I want to do basically is, since it was a successful build until yesterday, I want to go back to that build, so that at least the website is functioning properly and then just run the build with only one developer changes and not the ones that messed up the build.. thanks for the help. Can I do this with teamcity..
You can run a "history" build in TeamCity, selecting a change in the Custom run build dialog (click on ellipsis of the "Run..." button). If you want then use the artifacts in other builds, you can use "Promote" action from the finished build's "Build Actions".
Or you can use a usual approach to revert the changes in the version control and trigger a new build in TeamCity manually.
Related
When I build a project in CLion, it also refreshes all of my project files (after the build, actually) - and if I have a lot of them, mounted from a remote server via a slow(ish) network, that can take some time. Can I avoid this refresh somehow?
In CLion 2020.2 and later, you can tell the app not to have to wait until the refresh is complete to consider the build concluded and to allow you to continue with other work.
To do this:
On the menus, choose "Find > Action", then type in "Registry".
Choose the Registry action; you've now opened the CLion registry (yes, it exists).
Type in: cidr.asynchronous.refresh.after.build
Check the box on the value column.
Reference: Here.
I have created a task group for build pipeline. One of the steps in it is "Publish Build Artifacts" with path to publish as $(Build.ArtifactStagingDirectory) and "Artifact publish location" as "Azure Pipelines/TFS" (the other option being "A file share".
Once my build is successful, I want to "release". I created a new set of task group to first install NUnit Console runner, than Install NUnit3 Test adapter (both powershell scripts).
My next step is to run "Visual Studio Test Platform Installer" after which I want to run all my tests to make sure they are passing. In this step one of the required parameters is "Search Folder".
If I give it the value $(System.DefaultWorkingDirectory), it works fine. But it feels like I should be using a variable that's specific to the build and not system level.
Can someone please clarify what I should be using? Am I thinking right that the system level variable would be too low and I should be using something closer to the build artifacts? when I use Build.ArtifactStagingDirectory, it fails saying it could not find my test dlls.
You can keep use the variable System.DefaultWorkingDirectory, is not "system" scope variable, in each pipeline the value will point to correct artifacts.
More info you can find here.
I upgraded my .NET Core 2.1 project to Angular 6 and everything seems to be working correctly except for hot-updates. Before updating it was possible to update the TypeScript and VS would re-compile and reload the browser, now that seems to be broken along with having to manually run ng build to recompile the scripts, VS doesn't seem to recompile automatically anymore.
Is there a setting, possibly in angular.json that I need to set to enable the development server?
Update
For some reason, Hot Updates started working temporarily and not sure what I did to get it to start/stop working. When I start a debug session and update any of the .ts files, I can see the compiler output succeeding but when I refresh my browser I don't see any of the changes unless I manually build the project using the ng build.
I am starting to think that there is some miscommunication going on somewhere or possibly an error somewhere that isn't being picked up by the compiler causing something not to update?
Another thing I noticed while watching my output window is my site starts running on localhost:44359 but in the output, it says Angular Live Development Server is listening on localhost:55287 should these ports match?
one last observation I have made is after a change has been made during a debug session the output window lists all the chunks just like when running it manually with the exception it outputs i ｢wdm｣: Compiled successfully could something be corrupt or is this simply an output bug?
After a ton of messing around, I finally got this working and thought I would share what is going on.
When you run ng build it compiles and outputs to the ClientApp/dist folder. When you start the Debug Session your project uses this version. If you change a file at runtime it will re-compile the files but it will not overwrite the compiled files in the dist directory. I think because the files were manually generated outside of the UI, VS thinks it can not overwrite them.
So if you start running into this same problem luckily there is an easy fix, simply delete the ClientApp/dist folder before you start the Debug Session. Visual Studio will compile the files in the background and when you update a source file or style sheet your browser should refresh automatically.
Update
Another thing I found is if you need to manually run ng build there is another way to keep the files up-to-date at least (requiring reload):
package.json
"scripts": {
"ng": "ng",
"start": "ng serve",
"build": "ng build",
"test": "ng test",
"lint": "ng lint",
"e2e": "ng e2e",
"debug": "ng serve --watch",
},
Then run ng build --watch instead of ng build this will put the prompt into a watch mode (press ctrl c to end), then every time you change one of the source files it will update. I added the "debug" because I wasn't sure if it would mess with the production, always safe to keep things existing or default if you can as a backup.
Then in Startup.cs (Configure(…)) update the server to use the new "debug":
spa.UseAngularCliServer(npmScript: "debug");
Update - 2
Another thing that I have found when using Angular and VS (2017) is if you happen to have an error somewhere in your code that isn't picked up by the cli compiler, especially in any of the constructors or ngOnInit() functions, it will hang up the Angular Service even after shutdown, making it seem like the hot-updates are no longer working. This will lead to complete Madness because none of the changes or updates will be loaded until the service is shutdown.
Another possible cause are errors when compiling .scss or Angular. Check the "Output" window for any Angular-cli Errors or in the Browsers Output.
After shutting down VS, make sure that VSCompiler.exe, any extra Console Windows Host (Angular Server, not the one running under the SQL User i.e. MSSQLFDLauncher... ) and any Visual Studio services are shutdown in your Task Manager.
I realized that it was actually an ERROR in MY CODE that was causing everything to stop working or not work at all. Angular and .NET will NOT always throw an error, sometimes the errors are simply skipped (especially when there are syntax errors) or output in the midst of all the other outputs.
More than likely if things stop working, it is either because of an error or some other reason that caused the compiler to stop responding. One last area to double check are your package.json and angular.json, especially any paths, then run the following and keep an eye on the output for updates that need to be made:
ng update
npm update
npm rebuild
npm install
The default .json files should work right out of the package, try to revert back to those to check your configuration. Deleting the dist folder basically is a shortcut for the above (minus the actual output, let VS compile before Debug), forcing angular to recompile everything but keep in mind that if the service is hung up, it won't matter what you do until that service is stopped.
Short answer.
Delete 'Dist' folder in ClientApp folder. in VisualStudio
and Reboot and Run
I have passed trought the same problem.
You have two options:
Delete the "dist" folder(this folder will be recreated everytime you use 'ng-build')
Make the implementation equals the link below. This implementation makes the application ignore the dist folder. It will only be used at production environment.
Implementation
I think the second solution is better, because you don't have to delete the "dist" folder everytime you want to debug your application.
I have a problem in Team Explorer (VS2017) where I branch my code from the master and call it test (for example).
When I made changes in test branch and switched back to master, the changes in the test branch is also showing in master.
I don't understand why this is happening, I only noticing this after I upgraded from VS2015.
I have uninstalled VS2015 and I cannot go back and verify that this is a problem with VS2017.
Is there a settings that I have overlooked in VS2017?
Team Explorer will not automatically merge the test branch back into master (in VS2017 or VS2015), so let's look at your workflow that leads to this result. Could you please list for me each step you take when starting at the master branch, creating the test branch, committing changes, etc. If possible, screenshots at each step may help me look for other clues.
Thanks!
I want to get rid of the dialog saying
There were build errors. Would you like to continue and run tests from
the last successful build
when I am running unit tests (I use test -> run -> all tests).
How do I do that? I already know how to disable it when running a normal project.
I also want to know how this can ever be a useful feature?
How do I do that?
You can't.
I also want to know how this can ever be a useful feature?
I find it useful when I am working closely with someone who is configuring test data. I can re-run tests to ensure new test data is valid, without having to worry about compiling any changes that I have done in the meantime.
For example if someone has changed some data in a database, I want to be able to run my tests to ensure that this new data is valid, and I want to be able to run the tests whether the current state of my code compiles or not.
For Visual Studio 2017 / MSTestV2 you can do:
Tools > Options > Project and Solutions > Build and Run
"On Run, when build or deployment errors occur:" "Do not launch"