I have email and slack notifications configured for travis build failures. Currently It sends notifications for build failure of every branch. Since every developer does creates lot of branches, the mails come in a large number which sound like spam. I would want to restrict the mails only for failures of develop branch.
My configuration in .travis.yml is something like this.
notifications:
email:
recipients:
- xyz#abc.com
branches:
only: develop
on_success: change
on_failure: always
Is this branch specific alerts are really supported, if yes how do you do it ?
For your specific query about if branch specific notification is supported by Travis currently, the answer is NO. Below is from the Travis documentation:
There is currently no way of limiting the notification to a specific branch, but the payload will contain all relevant data to do so at the receiving end
So currently the branch specific notification is not supported by Travis, but would need to be implemented separately by consuming the webhook payload from Travis.
Update:
(Courtesy #LucasCimon) There is an open GitHub issue to track this feature request.
Related
On GitHub I get email notifications for repositories I "watch".
I can choose to disable email notifications for a specific repository:
Watch notification settings per repo
Or I can do it globally in my settings: personal settings
But as a repo owner, can I disable notifications for other users watching my repo?
I plan to build a somewhat more complicated GitHub Action and I suspect it is going to require some trial and error to get it right. I would like to prevent "watchers" getting notifications every time the Action starts & fails or gets aborted while I experiment.
To do this, you could do your experiments in a temporary fork of your repo.
Currently, our team has limited GitHub actions in minutes, so I would only like to run GitHub actions when the WIP flag is not present.
Currently we use this plugin WIP to check if a branch is work in progress.
Is there a way that if the commit is flagged as WIP, that the GitHub actions to not trigger so we can conserve our monthly minutes allowance?
You should be able to use the pull_request event with the ready_for_review or even review_requested tags.
This example will only run when a pull request is marked ready for review.
on:
pull_request:
types: [ready_for_review]
Draft pull requests
Pull request trigger event
I'm using a build policy on one of my Azure DevOps git branches.
Is there any way of requiring a manually triggered branch build policy be run again if the source branch is updated?
My branch policy is set to Manual trigger. We use Manual instead of Automatic to reduce the number of builds (we use self hosted build server) running on our CI server as we typically open PR's early to provide feedback and facilitate conversation around code.
If the trigger was set to automatic, then any time source branch is updated a new build is queued. This isn't case with Manual. I had situation where build policy passed but then a further commit was made to branch and the reviewer approved. But the build was not manually triggered again and the last commit & push introduced a bug. I'd like the build validation policy to either reset or fail every time the source branch is updated similar to how code reviewer votes are reset after a push.
Is this possible?
I do not think this is currently possible, it has been raised on the Developer community as a feature request / issue, so I would encourage you to up-vote this here.
A solution for our scenario (too many builds were being queued, because Code Reviews come back with changes) was to use Pull Request drafts.
Sprint 143 - Draft Pull Request
When creating a PR, you can click Create as Draft in the drop down beside the Create button.
Basically whenever somebody raises a PR on my repository, I want to ensure that the person raising the PR has performed some actions (running a script etc.)
So is there a way to set up some rule or some alert so as to remind the person to perform that action before raising the PR.
You should use something called integration. Here you can see the GitHub Integrations Directory.
My favorite is Travis CI–you set it up using a .travis.yml file and then after the commits are pushed the tests are run and Travis sends the status response which will be visible to in the Pull request.
However, this can't stop the user to submit the pull request.
Like I mentioned, you cannot stop the user to open pull requests but you can tell him/her the steps how to contribute using the CONTRIBUTING.md in your project. Then when somebody opens a pull request or issue will see this alert:
Is it possible to merge pull request automaticaly to master branch on github after success of travis test webhook?
You can use Mergify to do this.
It allows to configure rules and define criteria for your pull request to be automatically merged. In your case, setting something like "Travis check is OK and one reviewer approved the PR" would allow the PR to be automatically merged.
(Disclosure: I'm part of the Mergify team.)
You can most probably add an after_success action to your .travis.yml that would merge the PR using GitHub API. I do not know of any ready to use script for this, but there is no reason for it to be hard. Special care needed for authentication ...
GitHub recently shipped this auto-merge feature in beta. To use this, you can enable it in the repo settings. Just keep in mind you will need to add branch protection rules as well.
See the documentation for more info.
https://docs.github.com/en/free-pro-team#latest/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
I work on a project that requires pull requests to be up to date with the target branch, and also to have passed all the checks before merging.
This means we can often be waiting for checks to finish, only to find a new commit has been made to the target branch, which requires the pull request to be synchronised and the checks to run all over again. I wanted a simple app to merge the PR automatically once the checks are successful, so I created one.
Mergery is:
Free, including for private repositories.
Fast. It's event-driven, it doesn't run on a schedule.
Simple. No configuration required. Just label your PRs with automerge.