For internal reasons, one of my jobs is able to run concurrently, but new builds abort themselves if another build is already running (disabling concurrency doesn't help, since I don't want new jobs to be scheduled for execution once the current build is done).
However, this behaviour is detrimental to the job status preview (the colored ball next to the job name when inside the job's parent folder). It often shows the status as "aborted", which is undesirable - I want to view the latest running build as the source of the job status.
I tried deleting aborted builds from within their own execution, but that's unfortunately neither trivial nor stable, and thus not suitable for this situation. I could probably get a workaround running that deletes them from a separate job, but that's not ideal either.
Anyway, I'm now hoping that I can just tell Jenkins to ignore "aborted" builds in the calculation of the job preview. Unfortunately, I wasn't able to find a setting or plugin that allows me to do this.
Is this possible at all? Or do I need to find another way?
Would something like this help?
https://plugins.jenkins.io/build-blocker-plugin/
I haven't used it myself but it supports blocking builds completely if a build is already running.
I'm having some difficulties in getting this one working.
How would I have to configure a job in Jenkins to call some script on a node, the node to execute and when exiting, the job to not declare the build finished but to wait for a certain amount of time and to call again the script. The waiting period would have to be dynamically calculated at runtime based on a target start time. Such a build would have to be stopped by some user input and not by aborting the build.
I know pipelining might be needed in this case but I'm not very sure how the build history would look like as I intend to have only one build appearing in there not a bunch of builds spawned by the main one. Hopefully, I was able to make myself easy to understand.
Thank you very much.
We just started using Visual Studio Release Management for one of our projects, and we're already having some problems with how we are doing things.
For now, we've created a single release stage, which is responsible for deploying our build artifacts to a dedicated virtual machine for testing. We intend to use this machine to run our integration tests later on.
Right now, we have a gated checkin build process: each checkin fires all the unit tests and we configured the release trigger to happen on this build also. At first, it seemed plausible that, after each checkin, the project was deployed and the integration tests were executed. We noticed that all released builds were polluting the console on Release Management, and that all builds were being marked as "Retain Indefinitely" and our drop folder location was growing fast (after seeing that, it makes sense that the tool automatically does this, since one could promote any build to another stage and the artifacts need to be persisted).
The question then is: what are we doing wrong? I've been thinking about this and it really does not make any sense to "release" every checkin. We should probably be starting this release process when a sprint ends, a point that can be considered a "release candidate".
If we do that though, how and when would we run our automated integration tests? I mean, a deployment process is required for running those in our case, and if we try to use other means to achieve that (like the LabTemplate build process) we will end up duplicating deployment code.
What is the best approach here?
It's tough to say without being inside your organization and looking at how you do things, but I'll take a stab.
First, I generally avoid gated checkin builds unless there's a frequent problem with broken builds. If broken builds aren't a pain point, don't use gated checkin. Why? Simple: If your build/test process takes 10 minutes to run, that's 10 minutes that I have to wait to know whether I can keep working, or if I'm going to get my changes kicked back out at me. It discourages small, frequent checkins and encourages giant, contextless checkins.
It's also 10 minutes that Developer B has to wait to grab Developer A's latest changes. If Developer B needs that checkin to keep working, that's wasted time. Trust your CI process to catch a broken build and your developers to take responsibility and fix them on the rare occasions when they occur.
It's more appropriate (depending on your branching strategy) to do a gated checkin against your trunk, and then CI builds against your dev/feature branches. Of course, that opens up the whole "how do I build once/deploy many when I have multiple branches?" can of worms. :)
If your integration tests are slow and require a deployment to succeed, they're probably not good candidates to run as part of CI. Have a CI/gated checkin build that just:
Builds
Runs fast unit tests
Runs high-priority, non-deployment-based integration tests
Then, have a second build (either scheduled, or rolling) that actually deploys and runs the whole test suite. You can schedule it according to your tastes -- I usually go with one at noon (or whatever passes for "lunch break" among the team), and one at midnight. That way you get a tested build from the morning's work, and one from the afternoon's work.
Using the Release Default Template, you can target your scheduled builds to just go as far as your "dev" (/test/integration/whatever you call it) stage. When you're ready to actually release a build, you can kick off a new release using that specific build that targets Production and let it go through all your stages normally.
Don't get tripped up on the 'Release' word. In MS Release Management (RM), creating a Release does not necessarily mean you will have this code delivered to your customers / not even that it has the quality to move out of dev. It only means you are putting a version of the code on your Release Path. This version/release can stop right in the first stage and that is ok.
Let's say you have a Release Path consisting of Dev, QA, Prod. In the course of a month, you may end up releasing 100 times in Dev, but only 5 times in QA and once in Prod.
You should drive to get each check-in deployed and integration tested. If tests takes a long time, only do the minimal during (gated or not) check-in (for example, unit tests + deployment), and the rest in your second stage of Release Path (which should be automatically triggered after first stage completes). It does not matter if second stage takes a long time. As a dev, check-in, once build completes successfully (and first stage), expect the rest to go smoothly and continue on your next task. (Note that only result of the first stage impacts your TFS build).
Most of the time, deployment and rest will run fine and so there won't be any impact to dev. Every now and then, you will have a failure in first stage, now the dev will interrupt his new work and get a resolution asap.
As for the issue that every build is kept indefinitely, for the time being, that is a side effect of RM. Current customers need to do the clean up manually (or script it). In the coming releases, a new retention policy for releases/builds will be put in place to improve this. This has not been worked on yet, but the intention would be to, for example, instruct RM to keep all releases that went to Prod, keep only the last 5 that went to QA and keep only the last 2 that went to Dev.
This is not a simple question, so also the answer must be articulated.
First of all, you will never keep all of your builds; the older a build, the less interesting to anyone; a build that doesn't get deployed in production is overtaken by builds that reaches that stage.
A team must agree on the criteria that makes a build interesting to keep around and how long to keep it. Define a policy for builds shipped to production or customers: how long do you support them? Until the next release, until the following one, for five years? Potentially shippable builds, still not in your customers' hands, are superseded by newer, so you can use a numeric or a temporal criteria (TFS implements only the first, as the second is more error-prone). Often you have more than one shippable build, when you want a safety net option and being able select from a pool which deliver (the one with more manageable bugs).
The TFS "Retain Indefinitely" should be used when you cannot automate the previous criteria, so you switch to a manually implemented policy. Indefinitely is not forever, means for an unknown time interval.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 9 years ago.
I am using the Jenkins matrix plugin for testing my project. I have an upstream, kick-off build that is fired of every night at a fixed time. This build performs a checkout and part one of the tests. It then passes the subversion url (SVN_URL) and revision (SVN_REVISION) to a downstream build. The downstream build then uses the passed in subversion url and revision to checkout the source (this way, I know that both the upstream and downstream builds are targeting the same revision), and performs part two of the tests.
The problem I have is that the downstream job sometimes doesn't run anything saying that there were no changes in the checked out source since the last build (no change for since the previous build). I would like to get the downstream build to build every single time it is invoked, even if there are no changes. Any pointers on how to do that?
Thanks
(Edited in reponse to question)
Detailed jobs description:
1. Kickoff job. Run periodically. Captures SVN_URL and SVN_REVISION. Fires of part1-job and part2-job. Does not do anything else.
2. part1-job and part2-job are matrix jobs that do not have any triggers on them. They are merely run by the kickoff job.
part2-job is where I have the problem. Curiosly, the problem mentioned above does not happen for part1-job.
You may find that storing the build output from the initial build and running the downstream job based on that artifact to be a solution to this problem. I'm making some assumptions here about what you're doing in the initial and subsequent jobs, but our experience might be helpful.
For some tests where we perform a longer test after an initial build & test are successful, we now use the Artifact system to store the build results from the first build and then retrieve those at the beginning of the next test for execution. This works particularly well for lengthy build processes where you may need more than one test to run in parallel.
For example, our system looked something like this:
Build task
GUI Test on OS X 10.6
GUI Test on OS X 10.7
GUI Test on OS X 10.8
Initially, we ran these serially (all in one big build task), but then we changed our testing systems so that we could run the GUI tests in parallel and needed an efficient way to take the build output from a specific job and run it on each of the test environments in parallel.
Our new system runs like this:
Build task with Post Build action to Archive Artifacts
3 different tasks that each run the GUI tests in one environment, each of which begins by copying the artifacts from the first build stage (using Upstream Build that triggered this Job) and then using those artifacts as the execution targets for the test.
Now our tests run in parallel and are guaranteed to use the identical build. This has the added bonus that the each build is only run once.
As an added bonus, we reduced the 3 tasks doing the GUI test to a single matrix task, but that's probably not relevant for your purposes (however, it's sure saved a lot of work for us).
I would like to make ANT process wait for another build or task to finish.
The situation is: I execute a few ANT builds simultaneously. In these builds there are tasks to test the apps. Unfortunately, only one flexunit task can be run at the same time, because it uses net socket to communicate with the AIR app.
The build process should wait for the end of the tasks from other build processes before starting its task.
How to achieve that?
Thank you for any hints,
Rafal
Use the <waitfor> task with your choice of synchronization.
I always use an "IGotTheResourceSoYouCantHaveIt" file that gets created after <waitfor> and deleted when I'm done with it.
Details:
delete the file in some higher-level "clean" so that if a build aborts it gets deleted eventually.
there's a small race condition between the <waitfor> and creating the file. In my use, it's not worth worrying about.