I created a Pull Request which triggers the build and the build was successful, but after some time my build status changed to "build expired" so to finish the pull request I need to trigger it one more time. So the question is: Why has this happened and how do I avoid an expired build?
"Build Expired" is a feature of branch policies.
Set a build expiration to make sure that updates to your protected branch don't break changes in open pull requests.
Always require a new build
This option sets the build policy status in a pull request to "failed" when the protected branch is updated. You must re-queue a build to refresh the build status. This setting ensures that the changes in pull requests build successfully even as the protected branch changes. This option is best for teams that have important branches with a lower volume of changes. Teams working in busy development branches may find it disruptive to wait for a build to complete every time the protected branch is updated.
Require a new build if older than ... hours
This option expires the current policy status when the protected branch updates if the passing build is older than the threshold entered. This option is a compromise between always requiring a build when the protected branch updates and never requiring one. This choice is excellent for reducing the number of builds when your protected branch has frequent updates.
Don't require a new build
Updates to the protected branch do not change the policy status. This reduces the number of builds for your branch, but can cause problems when closing pull requests that haven't been updated recently.
More details on "Branch Policies"
On the overview of the push request, next to "Build Expired" - click on the ellipses (3 dots to the right) and select "Queue Build". If it fails, pull master, merge it into your branch and re-push.
Related
I'm setting up a new Jenkins job using multibranch pipeline and I have noticed that when a branch is deleted, it only has a strikethrough and isn't actually removed on Jenkins. This is solved by re-running branch indexing. However, I cannot really use this as it will also cause every other branch to rebuild (a consequence of how the repository is updated). Is there some custom code or pipeline/script I can run to re-index without building?
I've already looked at various UI methods such as suppressing SCM triggers, but this also negates push events from Github which is something we want to use.
The deleted/merged branch build will disappear after a period of time (<24 hours). It is not removed immediately to show the recently deleted/merged branches and give a chance to review the prior build statuses. It is relatively harmless since the jobs for these branches are deactivated (read-only).
Note that the removal is based on the branch indexing job running at regular interval, so if you have this disabled, it probably won't do it (not sure the SCM webhook calls are enough).
My team leader wants to get notified whenever changes are made to a specific Project.
Is there a possibility within Git to supervise specific Folders or Files and get notifications if the code changes?
If you are just looking for an FYI, you can configure a build job with continuous integration enabled and the 'Path Filters' set to the folders or files you want to supervise. This build definition could be empty as you are not actually trying to build, but rather kick off a notification workflow.
This would create a build each time a file or folder changes that is in the path filter. You then have to decide how you would like to be notified. Here you have a couple options, but 2 fairly easy ones would be as follow:
Use a Send Email task from the VSTS Marketplace, there are a number of options depending on your needs. VSTS Marketplace Email Tasks
Configure a new 'Notification Subscription' under Settings -> Notifications and set this up to send an email to whomever is doing the monitoring any time a build completes for that definition.
Note: if you want to prevent changes to these areas, then you should use branch policies suggested by Daniel Mann.
Note 2: Depending on the volume, if there are tons of changes to these paths, you may overwhelm your build server or consume all your build minutes quickly.
You can configure branch policies for your repository to require a code review; this will trigger a notification.
The branch policy can be limited require review only for certain files or folders.
I've set up a number of Multibranch Pipeline jobs in Jenkins (running 2.46.2 LTS, Branch API 2.0.8, GitHub Branch Source 2.0.5, and Pipeline Multibranch 2.14) and have just noted that branch indexing -- and thus any cleanup of old branches -- does not appear to be triggered by the webhook calls from GitHub. It only appears to be triggered if someone manually clicks the "Scan Repository Now" link, or if the job configuration in Jenkins is re-saved. I'm using the timestamp shown in the "Scan Repository Log" page as an indication of when the branch indexing occurs.
It seems that new branches or changes to existing ones are being detected correctly and built, so the webhooks from source control (GitHub) are working, but was surprised that this wasn't also triggering the branch indexing and thus the old branch cleanup. I just can't tell from the documentation whether this is correct and expected behavior or if something is incorrect in my setup.
I note that the help text for the "Periodically if not otherwise run" setting says:
Some kinds of folders are reindexed automatically and immediately upon receipt of an external event. For example, a multi-branch project will recheck its SCM repository for new or removed or modified branches when it receives an SCM change notification. (Push notification may be configured as per the SCM plugin used for each respective branch source.) Such notifications can occasionally be unreliable, however, or Jenkins might not even be running to receive them. In some cases no immediate notification is even possible, for example because Jenkins is behind a firewall and can only poll an external system.
This trigger allows for a periodic fallback, but when necessary. If no indexing has been performed in the specified interval, then an indexing will be scheduled. For example, in the case of a multi-branch project, if the source control system is not configured for push notification, set a short interval (most people will pick between 15 minutes and 1 hour). If the source control system is configured for push notification, set an interval that corresponds to the maximum acceptable delay in the event of a lost push notification as the last commit of the day. (Subsequent commits should trigger indexing anyway and result in the commit being picked up, so most people will pick between 4 hours and 1 day.)
This certainly implies that indexing of a Multibranch Pipeline job should be re-triggered by branch events (e.g., pushes from GitHub via webhook), but the timestamp on my indexing log seems to belie that.
So, is what I'm observing the intended behavior? If so, and I want a regular cleanup of old branches, do I need to select the "Periodically if not otherwise run" checkbox under "Scan repository triggers"? Or is there something wrong with my setup, which is preventing it from working as intended?
According to the official documentation:
By default, Jenkins will not automatically re-index the repository for branch additions or deletions (unless using an Organization Folder), so it is often useful to configure a Multibranch Pipeline to periodically re-index in the configuration.
I depend on "Periodically if not otherwise run" for 1) cleanup of branches and 2) creation of container jobs for brand new repos (i use "Bitbucket Team/Project", the bitbucket version of "Github Organization", which basically creates a multibranch pipeline for every repo in your organization). I have "Periodically if not otherwise run" set to run once a day for each project.
It does seem like these things could work via webhook, but they do not in my experience.
We have a team alert in TFS 2015 that sends an email out to all developers whenever one of our builds fails.
I'd like to modify it to not issue emails when someone fails a private build, or a private gated check-in fails (we don't use gated check-ins by default). In these cases, a separate alert will issue to just the individual developer.
Below is the current criteria
However, when I tried to run a manual gated check-in just now, the build failure issued an email to the entire team.
What additional conditions are required to ensure that these emails are not generated when I create a build using a shelveset - whether or not I choose to automatically commit the changes on success.
There is no private gated check-in build, "gated check-in build" is not Private build.
You queue a private build if you want to build the changes that you
have put into a shelveset.
More detail info with private build in TFS, please refer this MSDN link:
Queue a build
When you are going to use the private build and not issue emails when someone fails, you can add a build reason not contain check in shelvest as a workaroud.
The part above your screen shot is the part that identifies if the alert is being configured for a Team (sends to everyone) or a personal alert (just to you).
I would like to achieve the following setup in Travis CI.
Do a build whenever commits are pushed to dev or release branches only.
Disable builds whenever commits are pushed to any other branch apart from dev or release but build pull requests.
If a developer is really interested to know if his commits are good, then he should be able to kick start a build on Travis CI explicitly by choosing a branch/commit.
From reading the documentation on Travis CI and some blog posts, I see that I can achieve "1." and "2."
Does anyone know how to make "3." work?
Update-1:
The reason I want scenario "3." is because the developers in our team (or in general any other team) make several commits and push them even before they send out a pull request. Building for every single commit of a private branch even before it goes for a pull request is causing lot of requests to queue up in the Travis CI queue which unnecessarily blocks developers who really care to verify a particular commit to check if everything is good or not before sending out a pull request.
Having the following is just fine for us:
Build on every commit push to dev and release branches
Build on every commit pushed to a pull request
You can easily achieve 1 and 2 by whitelisting the branches you want to see push builds for:
branches:
only:
- dev
- release
For reference, see https://docs.travis-ci.com/user/customizing-the-build/#Whitelisting-or-blacklisting-branches.
You can achieve 3 only if your developers open a PR against one of the whitelisted branches.
I'd personally recommend to open a PR as early as possible (after the first commit), as it makes work in progress visible to everyone who is interested.