Right now wercker builds a build when changes were made to git repo. How do I set up wercker so it builds for example every 12 or 8 hours every day ?
This is not possible yet, although it has been suggested here. But you could create a small program the calls the api to trigger builds periodically.
Related
We are currently using bitbucket cloud to host our grails-app repository. We want to set up some pipelines to do things like run unit tests and make sure the app compiles before being able to merge a branch to master.
I know this can pretty easily be done by letting them host the pipeline and committing a well written pipe file, however there is a problem standing that our app is very large, and even on brand new macbook pros takes 20 minutes to compile, on some older ones it can take 2 hours or more. Grails, thankfully, only compiles files that have changes in them from the last compilation. However, this can't be used on a bitbucket pipe that's working off a fresh pull of the app every time it runs.
My solution to this was wanting to set up a pipeline to run for us internally so that it can already have the app pulled, and just switch to the desired branch and run from there. This still might take time if switching between 2 very diverged branches, but it's better than compiling from fresh every time.
I can't seem to find any documentation on hosting a pipeline internally with bitbucket cloud, does anyone know if this is possible, and if so where there is documentation for it?
It would also be acceptable to find a solution to the long compilation problem itself with bitbucket hosted pipelines.
A few weeks ago, self hosted runners was made available as a public beta. Here are the details: https://community.atlassian.com/t5/Bitbucket-Pipelines-articles/Bitbucket-Pipelines-Runners-is-now-in-open-beta/ba-p/1691022
Additionally, if you're looking to retain some of your files from one build to the next to save doing the same work over and over again, have a look at caches: https://support.atlassian.com/bitbucket-cloud/docs/cache-dependencies/ there are some built ones that you could use, but you can define your own custom ones as well. Essentially it's just a way of preserving the contents of a directory for a future build.
I have a TeamCity build configuration which has two build steps with console commands. One of the scripts is expected to run for 15 minutes to build the project.
When I run the build, I see the progress bar with warning icon. Details say:
7m:20s passed of 12s initially estimated
7m:07s overtime
I don't understand, why TeamCity decided that both steps should take just 12 seconds. It's a fresh install of TeamCity, I'm the admin of the TeamCity and I haven't touched any timeout settings.
I searched TeamCity docs and entire Internet for TeamCity overtime settings. I found only settings for failure triggers, but I don't need it, I just need some way to tell TeamCity that it should not make assumptions how long my custom scripts should execute.
How do I get rid of these Overtime warnings?
The estimate is calculated based on the duration of the latest builds in the history of the build configuration. So there should be several builds in history (at least 10) to calculate the estimate time. More details can be found here.
It would be very nice if failed and cancelled builds were not used to calculate the estimated duration of a job.
I have a job which has succeeded exactly twice, both times taking ~13 hours (the expected length of time for this job). Whilst getting it to work, there were 4 failed and 2 cancelled builds, each taking anything from <1 second to 15 minutes.
I've also had one legitimate failure (owing to a network outage) which ran for 1 hour and 45 minutes.
For some reason (which I can't fathom), the estimated time for the currently-running build is 23m47s (currently 4 hours 30 minutes into overtime). As this runs once a month, it would appear that it will take ~10 months for the estimated time to work itself out, so long as it never fails.
The heuristic is broken.
How do you people handle the scenario of having to build the solution multiple times every day during the development process? Our .sln takes about 2 mins to build, but waiting for those 2 minutes every day, multiple times a day during development adds to a significant number and also breaks the coding flow. Is there a better way to handle this necessity? Something that will continue to build the solution and run the test on background without the developer having to hit ctrl+shift+B and wait for the build to complete, before checking in the changes into TFS?
VS doesn't support building the same solution before the previous one completes. But you can achieve your requirement by using TFS Build.
When you checkin your solution into TFS, you can create a Dev branch of this solution. All changes will be checked in to Dev branch and automatically build (Gated checkin). Once the build result is what you want, then merge from Dev branch to the original solution.
Looks like you actually working with Builds check in policy which only allows code to be checked in after build succeed. If so, just as you described, you can't work on the project during the build. You have to wait for it to complete.
We have a project using TeamCity which Triggers a build when changes are detected to the VCS with a 60 seconds quiet period.
I want to configure this trigger in such a way that the VCS trigger will not build if the last successful build was within 1 hours time. However, if there is no build detected in the past 1 hour and a change is detected in the VCS then the build should trigger instantly.
Is there a way I can achieve this task in TeamCity?
Thanks,
Vishal
As far as I understand you want to trigger not more than one build per hour. Currently it is not possible to configure in TeamCity. Here is the related request: https://youtrack.jetbrains.com/issue/TW-26302. Please vote for it.
I have a setup where our code builds to dev every 5 hours on a schedule trigger. This works great, but the downside that the code could sit in teamcity for hours before it triggers and alerts us to a build error.
Is there a way to have a VCS trigger also run the build as soon as its checked in, but passing something to our NANT script to say "just build, don't deploy"?
I know I must be missing something.. is there any way to achieve this?
The only way I could think of was to have an entirely separate build configuration, but that seemed rather wasteful
You can setup a new build with a VCS trigger and then have that build have a env/system variable set that your build script can read to determine whether or not to deploy to dev.
See TeamCity Docs for information around this. I've used something like this in setting up builds before and it works well.