we have established a database size monitor release definition and would like to have it run/deploy every sunday at 11pm automatically.
I am checking out the artifacts schedule part
Is this how its done? Or does this create Only releases? Because we want them to get deployed automatically too of course, but as you can see highlighted below, it says creates a new release…doesn’t say deployment…
is there another way to make it deploy without having to create a release every time? so basically create one release and use that forever unless changes are made to the defintion. otherwise, there'll be a TON of release which wont be ideal...
There is not such a kind of schedule deployment based on a single same release. However, you could set release pipeline like this:
On the pipeline / artifacts, remove your schedule as you did.
Then on your environment, change the trigger to be after
release and enable the schedule, choosing when you want it to
start.
Also in your environment change the deployment queue settings to "deploy latest and cancel others".
Click on your artifact and enable the CD trigger.
As you can see under Triggers, define the trigger that will start deployment to this environment. When a CI build completed, it will start a release, then it will wait the schedule defined time and try to deploy to your environment set.
Once you build again, the previous release will be canceled to replace the new one. You maybe have more releases, but you won't deploy if there were no changes.
Hope this helps.
I need to schedule a Jenkins task so it runs once per day, but only if certain other tasks succeed at least once that day. That situation makes it similar to this other question, but none of the answers there describe how to deal with the contingencies I have.
My team has a Jenkins process that builds the software. We'll call that the Builder. Builder checks our GitHub repo every 15 minutes and runs if it sees a code change.
We have another task that runs simple tests. This entire test suite can finish in less than 15 minutes. This is the Short-Tests task. Short-Tests run every time Builder passes.
Lastly, we have a set of tests that take hours to run. Let's call these the Long-Tests. We want to run this once per day, but only if Builder and Short-Tests both pass. The Long-Tests start late at night so we can check the results the next morning.
Furthermore, we want to run Long-Tests only on the most recent successful build that day. If the most recent build failed, we want Jenkins to ignore that build and test using a previous build that passed.
If no builds pass that day, there is no need to run Long-Tests at all.
I can schedule Long-Tests for once per night like this, but please tell me how to set up the dependencies.
01 00 * * *
In order to get this behavior you need some kind of persistence to flag successful build and successful short test completion. There are several options available depending on your actual setup such as:
File based flag (writing to file on successful build / test)
Database flag (writing to database on successful build / test)
Git branch manipulation (pushing/merging to specific branch on successful build step, such as example given here: http://andrewtarry.com/jenkins_git_merges/).
Once you have your persistence setup, you can trigger builds either on change or periodically. For example following dependencies can be setup:
Push to Git code branch, triggers Jenkins Build job
For this step you need persistence, say pushing to git: Upon successful completion of build stage, short tests are triggered and, If successful, push to git "latest passing short test" branch is executed using Git Publisher plugin for example. This is to ensure that only last passed short test are going to be scheduled for long nightly tests.
Lastly, long tests are scheduled periodically, handling branch "latest passing short test".
This is just top level overview, since details depend a lot on your actual setup, permissions, git policies, type of Jenkins configuration etc.
I'm having some trouble preventing a Scheduled Build from being automatically kicked off after the same build has been trigger manually and no changes are present.
Problem: The Build is scheduled to go out at 3am everyday but only if any changes have been made (the Settings option ‘Build even if nothing has changed since the previous build’ is Unchecked). The problem is that if you trigger a manual build and no changes are made afterwards, the Scheduled Build is still going to get triggered even if there are no changes. Please follow the scenario bellow for an example:
Scenario:
Scheduled build gets kicked off today at 3am - assembly version changes to 1.0.0.1
On the same day, several changes are checked-in before noon.
The same Build is kicked off manually at 1pm - assembly version changes to 1.0.0.2
No more check-ins are made after the manual build from 1pm
The next day at 3am the Scheduled build gets triggered which it shouldn't have (assembly version changes to 1.0.0.3) since there were no check-ins since 1pm (triggered manually).
It seems like the 1pm build is not even being considered and accounted for.
It looks like TFS is taking in count check-ins since the last “Scheduled Build” rather than “the last completed Build” (same build definition) which in this case was the manually triggered one.
So my question is: “Is there any way we can prevent TFS from triggering Scheduled build if there were no check-ins after a manual build has been kicked off?”
Currently, it looks like TFS does not have that option anywhere in the Build Definition
Thank you in advance
In order to do this you would need to write your own scheduler that checked the previous manual build for you. You could write a TfsJob for this or even as a a scheduled powershell that runs at the allotted time...
I ran into this issue today as well.
It seems this is currently "by design".
Someone else posted a suggestion to "fix" this here:
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/5702884--build-even-if-nothing-has-changed-since-the-previ
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.
We've got a Jenkins setup where we do incremental builds on SCM change, validate and then if this works do a full build (from scratch). This basically works but we waste time doing full builds during the day that we don't normally use.
I know we could trigger full builds every night, but many of our branches won't change for a few days - and then we might get a rush of changes. Thus building every branch every night is wasteful too.
What I really want is some mechanism where we only do the full builds once (say at night) if there has been an SCM change and the incremental build and validate worked - there is no point auto-triggering full builds where the incremental build and validate failed. Actually just "the incremental build and validate worked" should suffice - as these normally just run on SCM change.
Any suggestions? Is there some Jenkins extension that would help with this?
To achieve what you've asked for you can create a new job that is the same as your existing one, but have it only poll the SCM once a day, for a nightly build.
Set the schedule to something like this: H H(0-5) * * *.
In your original job, remove the post-build triggering of a full build.
That will give you pretty much what you've asked for, except the nightly build will do an incremental build and then a full build if the incremental one succeeded, rather than just checking the result of the last incremental build.
BUT...
What is the cost of the 'waste' you are trying to avoid? How much does running a full build every night actually cost you? And wouldn't you be better off finding out when the full build is broken as soon as possible, i.e. during the day when it was broken rather than only the following morning?