A common problem I have with CruiseControl.net is when a project encounters an error (either related to the ccnet configuration or build errors) and once I fix the error I must start the project over from the start. But in some cases this means hours of work that doesn't need to be redone.
Is there a method or design philosophy that will allow me to run sections of projects with more granularity?
I was considering passing in a number when force building and using that to determine which "stage" of the build to start at.
Related
We are trying to get an old legacy code base under control while simultaneously developing new features. Currently the code compiles with a hell of a lot of compiler warnings and warnings from static code analyzers. For that reason it is not uncommon that code introducing new warnings reaches production simply because the new warning got lost in the shuffle.
Currently we are using Jenkins for nightly builds and make the build fail on new warnings. However, when Jenkins detects the new warnings the code was already merged a few hours ago. So we would like to not only shorten the feedback cycle but also ensure to only merge changes that do not introduce new warnings.
As far as I know it is possible to trigger a Jenkins build on a push to GitLab. But Jenkins can only compare the count of warnings to the previous build. But we would need to compare to a build of a different branch.
Can GitLab CI or a combination of GitLab EE and Jenkins somehow be configured to detect if a merge request introduces new warnings?
Yes that is possible but that's rather an open-ended question that will depend a lot on how long a build takes and how you will compare the outcomes.
You don't have to run only the checks on the branch you have checked out. You may set up two jobs in parallel that run tests on current branch and the develop branch, pass them as artifacts to a third job and compare them there.
You may want to store the state of a build on your develop branch and download the artifact to your current job and compare it against the local results. You could also store them in a database, on a file server or wherever else it's comfortable.
Finally you may try an external code quality tool like SonarQube which has greater insight into what's new and what's old.
In the meantime tools got developed that allow a workflow which is not perfect but comes quite close.
Jenkins has the Warnings Next Generation Plugin which can compare the warnings found in one Jenkins job to the warnings found in another Jenkins job. So we set up a job to compile our develop branch each time a new commit is pushed to it. We then use the results as baseline. Another job that gets triggered for each merge request in GitLab then uses this baseline to determine the new warnings introduced by the merge request.
This works reasonably well.
I have an Azure Web application that I checked into TFS yesterday with no issues. Upon checking in, the resource manager will inject our nuget packages and deploy if it builds successfully.
I made a few changes (added a class) and checked in today. I received this error on the build:
Here's the quote to help the future search bots:
Exit code 1 returned from process: file name 'tf', arguments 'vc unshelve Gated_xxxxxx;****** /loginType:OAuth /login:.,******** /noprompt'.
I looked into the log response, to see if I get more detail, but it says the exact same thing. I have not changed my password or username.
How can I debug this to figure out the issue?
UPDATE
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
To save others from the headache. The issue was that we had CI builds per project. A file from another project had snuck in as well. So I was checking in for 2 different projects on 2 different solutions (Which both go to the same TFS server). So make sure you only check in for that one project!
You can receive that error as well if you try to check in a file that is in a project that is not mapped in your build definition.
Let's say that you have a file named FileA.cs that is in a project named ProjectA.csproj. If you do changes in FileA.cs and this file is included in your changes, you need to map ProjectA.csproj in the Get source step of the build definition.
I've just realised that one of my Cruise Control.net code integration builds has been succeeding despite the fact that a project's missing from the solution (i.e. the solution file points to a project file that's missing from the disk). Does anyone know how to enforce a failure under these conditions?
After upgrading our solution to Visual Studio 2012 we are looking to take advantage of the new Code Analysis feature. However, it is taking too long to run, because it is rebuilding the project and dependant projects before it runs, even though the code has not changed and does not need a rebuild.
Is there a way to stop it rebuilding code if a rebuild is not required?
I believe Johns statement above to be incorrect.
In my experience, the projects always get rebuilt regardless of whether they are configured for code analysis or not.
I have a solution with over 100 projects. if I select 1 project and run code analysis on that project only, it rebuilds that project and all projects it is dependant on. It doesn't run code analysis on the other projects, but it still rebuilds them.
So why does it have to rebuild all the child projects to run code analysis?
If you are just starting to use code analysis, then you may be mistaking the symptoms. You are seeing:
e
1. Code analysis takes a substantial amount of time, and
2. During code analysis, the project builds
You may be combining these two symptoms and reaching the conclusion that code analysis is forcing a rebuild of your project. This would be a false assumption. Try this:
Ensure that your projects are configured to not run code analysis upon build
Rebuild your solution. Note how long it takes
Build (don't rebuild) your solution, but this time, note how long it takes
You will find that your solution actually "builds", but since the projects are up to date, the compilers and other tools do not run.
So, it's true that code analysis runs a build of your solution first, but it will be a build like #3 above - nothing has changed, so the tools won't run. Only the code analysis tool (FxCop) will run. This takes longer than you might expect, but it's worth it.
In our environment, I created a "Local" solution and project configuration, copied from "Debug". This configuration is mostly the same as "Debug", but does not run code analysis. This is what our developers use on a day to day basis. When code is checked into TFS, it starts a Continuous Integration (CI) build in the "Local" configuration, again, without code analysis.
On the other hand, the nightly build runs the "Debug" configuration, so it does run code analysis. I find that we don't need the results of a code analysis on every build, but it's damned well necessary once a day.
OBTW, Code Analysis is not new. If you look at that MSDN page you linked to, you'll find a 2010 version of the page in the "Other versions" dropdown. In fact, the code analysis feature was available as a Visual Studio add-in called "FxCop", before it became part of the product.
I have a project A ( DAL project ) that is relied upon by Projects B,C,D,E,F,G.
I currently have set up project triggers in the config of B,C,D,E,F,G and these are causing the projects to rebuild when project A successfully builds.
However, there is projects that are timing out as all the other projects are trying to be built at the same time.
Is there a way to stagger the build or get them to retry on failure of build?
Put them all in the same queue. CCNet only allows one project to build per queue.