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.
Related
I have a Jenkins Job that is running periodically (Every minute).
As so, I end up with thousands of logs that doesn't really matters to me and overload the space disk.
Is there a way to configure that job, in a way it will keep just the last 100 builds and delete the old ones?
I know this is possible manually, But I am looking for a way that I don't have to do it myself every time, I want the job, or another one to do it automatically.
You do not need to do that manually, you just configure the job to retain the # of builds to retain during creating the job. This again can be done when you create the job itself through a rest api, all you have to do is to set the appropriate values in the job's config.xml. You configure the job once and never have to worry, Jenkins automatically takes care of the clean-up.
Note
Once you configure the job, the next run will be over the threshold and trigger deleting the excess job logs.
Also, since LTS 2.204.6: Add globally configured build discarders that delete old builds not marked as "keep forever" even if there is no, or a less aggressive, per-project build discarder configured, executed periodically and after a build finishes
I'm a pretty new DevOps engineer, and i mostly deal with CI processes.
I'm wondering if it makes sense to define both nightly build And build on each push.
Seemingly, it doesn't make sense, since if the code is built after each push, why do you need to build at midnight, it was already built when you pushed it to the repository.
Am i right?
IMHO you are right - it does not make sense to have a fixed time schedule if at the same time you have a push trigger.
A reason why you still want to have a nightly build (or other fixed schedules) could be if you cannot run a full test with every build.
For example you could decide that you only do minimum tests (or smoketests) with every push triggered build, but once per day (e.g. night) you do a full test run.
As far as I know, the advantage of midnight build is that tasks with long running/deployment time can be run at midnight.
After these tasks run at midnight, you can directly view the results the next day.
In this case, you can set the condition for a specific task to control whether it runs at midnight. You could use $(Build.Reason) to judge it.
On the other hand , we recommend that you can set a specific time schedule trigger.
CI triggers cause a pipeline to run whenever you push an update to the specified branches or you push specified tags. The build is only triggered when the code changes.
Changes in the pipeline itself and the operating environment will not trigger the build.
But they can sometimes determine whether the project can run successfully.
In this case, the schedule trigger can run the build at a specific time to ensure that the project is executable.
I will share what we do and maybe help you:
We have three build tiers, one to cover a case like the Push example you pointed, other with a set of PowerShell tests, and a Scheduled one with full set of tests that takes around 5 hours.
As you can picture each case have their one scenario based on time a number of tests.
At work, we use TFS as our release management service, and the release is triggered from the push of source code from git.
We need to prevent that a release starts if the previous one isn't fully finished (we have releases with multiple environments).
I have already tried in the deployment queue settings, to limit at one the parallel deployments, but this seems to work only for the single environment
(if that environment has finished the next release can start with that environment, but the old release is still running for other environments)
Is it possible to achieve the behavior that I want with TFS? If so, how?
In VSTS, I have release definitions with one or more artifacts.
I've scheduled the release to each night automatically:
Release Definition -> Edit -> Pipeline -> Schedule icon in the Artifacts section.
However, sometimes I trigger the release manually or the source code has not changed and therefore there are no new artifacts since last release.
How to avoid releasing the same version multiple times?
You can change your release pipeline like this:
1 - On the pipeline / artifacts, remove your schedule. You will not need it.
2 - 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".
3 - Click on your artifact and enable the continuous deployment trigger.
So every time a build is completed, it will start a release, scheduling it to your defined time. If you build again, the previous release will be canceled to give place to the new one. You maybe can have more releases, but you won't deploy if there were no changes.
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