I have a build that polls SVN and checks for changes every hour. if it finds changes it starts building.
Right now if it sees changes and a previous build (from the same job) is running, it will queue the build and start it when the previous build finishes.
Is there an option to disable the queuing of multiple builds ?
Here's a workaround: let one job (Trigger) do the polling and then call the main job (MainJob) that will do the updating and building. You can even use the Parameterized Trigger Plugin to pass the SVN revisions and URIs. You then check off Block build when downstream project is building in Trigger.
To propagate change-sets from Trigger to MainJob use BlameSubversion Plugin.
(BTW, here's a neat trick: Trigger does not have to check out the whole SVN tree, you can check it out by hand with --set-depth empty in the working copy of Trigger).
Related
If there are multiple pushes to branch, Bamboo schedules separated builds for every push which creates redundancy on the queue. We only care about the last build with the latest changes for ours pull requests. Therefore, is there any way/configuration to cancel ongoing/scheduled builds if new build is scheduled?
I figured out Enable quiet period option (Quiet period allows you to delay building after a single commit is detected, aggregating multiple commits per build). However, quiet period is not the best way to handle the redundancy on the queue.
Does anybody have any idea?
A few things:
It is somewhat of an anti-pattern to avoid building each time code is committed. If you cancel an ongoing build, you could theoretically go all day without ever knowing if a commit at the beginning of the day broke the build if incoming commits keep cancelling the build. Taking this approach you would lose the benefits of having a continuous integration system.
If you only care about the builds going into your mainline branch then you can edit how branches are built by going to Plan Configuration -> Branches. You can select Manually or "When pull request is created". The latter will only trigger a branch build when the PR is created and is updated.
You can further limit what is running by using the Conditional tasks for Bamboo plugin. While not as clean as not starting a build, you could choose to only execute time consuming tasks when your main branch is building, which would allow for faster execution on branches.
Finally, you could theoretically use the REST API to create your own custom plugin/application that stops builds.
We have a teamcity build, triggered by git, that is doing git integration, sometimes checking into the current branch (it's updating the branch from another source). This obviously creates another check-in on the same branch, and causes the trigger to see it.
Ideally, I'd block the trigger from seeing that second check-in, but I can't seem to find a way of doing that - as what we are checking in is a conglomeration of changes from other sources. I know the last change is from the build system user, but can't see a way of excluding based on the result of the most recent change.
So I built something in the build script, that correctly ascertains we shouldn't go ahead with this build. I'm currently just failing - but this isn't actually an error case. I want to stop the current build without doing any further steps, but I want the result to be green, and everything to be fine. Is this possible? I tried doing the ##teamcity set status, but that didn't work.
I actually "solved" the problem, with a brain-dead but easy hack - I just set a variable "skip", and check it at the start of each subsequent step. Ugly, but for the moment - it works.
You can set a VCS trigger rule (5 Build Triggers) with an exclude rule that will not trigger when the build system user commits to your repository. The exclude rule would look something like this:
-:user=TeamCityUser
Hope this helps!
You can filter out triggers by commit messages. When checking-in from the build agent, always check in using a predefined and specific message. Then you can change the build trigger to not fire when that specific message is part of the commit
Is there a way to trigger a teamcity build only after a certain number of check ins. I tried checking build triggering in teamcity but can't find anything where I can specify the number of check in after whcih I want to trigger a build.
I don't think there is a built in solution to this, but there are some things you could do.
Build your own build trigger plugin as described in the documentation
You may be able to simulate what you want by setting a long quiet period in the VCS trigger.
Use a scheduled trigger to run every hour or more and set it to only run the build if changes are detected
Only the first option will trigger on a specific number of checkins, but the other two could reduce the number of builds you do a day.
You can also look into the artifact clean up rules to reduce the number of artifacts kept. Another option is to use pinned builds to pin one build a day (for example) that will not get cleaned up by the artifact clean up process.
I have created many build configurations in Hudson for a single solution (eg. Release, Debug, Test)
When I commit something wrong, I receive 1 build failed e-mail for every build configuration.
I would like to receive a single e-mail.
I think if I could to make one build dependent on the success or failure of another, I could receive less e-mails.
How to do that?
BTW: I use MsBuild, Subversion and NAnt
It sounds like you have multiple jobs (build configurations) for the same set of source code that are configured to always build. You could, as someone else suggested, use build triggers to chain these jobs together. However, if all the jobs run on each commit, I suggest combining the jobs into a single job with multiple steps. That way when one step fails, the entire build will fail, no unnecessary Hudson cycles will be spent, and you will not receive redundant emails. To add steps to a build, click "Add build step" and select "Invoke Ant" (or whatever other action you want it to take).
You can use the build trigger "build after other projects are build" to put projects up- or downstream from one another. Then you typically let the lighter builds go first (like simple compile).
Is there a way to configure Hudson to only execute Build or Post Build actions if there are changes in SVN/CVS
Thank you
You can have Hudson poll the SCM for changes and only do things if it finds changes.
Poll SCM: Configure Hudson to poll changes in
SCM.
Note that this is going to be an
expensive operation for CVS, as every
polling requires Hudson to scan the
entire workspace and verify it with
the server. Consider setting up a
"push" trigger to avoid this overhead,
as described in this document
You can also add something to your SCM post-commit hooks that will fire off a Hudson build.
Trigger builds remotely (e.g., from
scripts):
Enable this option if you would like
to trigger new builds by accessing a
special predefined URL (convenient for
scripts).
One typical example for this feature
would be to trigger new build from the
source control system's hook script,
when somebody has just committed a
change into the repository, or from a
script that parses your source control
email notifications.
You'll need to provide an
authorization token in the form of a
string so that only those who know it
would be able to remotely trigger this
project's builds.
It is not as simple as looking at the revision number (as stated elsewhere) unless your build is for the entire subversion repository. Typically you have projects sharing a single subversion repository and you are building some sub-tree. The global revision number doesn't help.
'svn info [url_to_subtree]' will show the Last Changed Date. You can parse this and figure out if it is later than your last build date and trigger a new build.