bluzi / travis-buddy Goto Github PK

Summary

Sometimes, repository owners configure TravisCI to execute multiple scripts that ends up generating the same output. These duplicate logs should be eliminated.

How to resolve?

In handlers/failure.handler.js you'll find a variable named jobs, that contains an array of executed scripts and their outputs - filter this variable and eliminate the duplicate logs before it's being used by the messageFormatter to generate the comment.

Often a PR keeps getting the same error for each push.
It would be more useful, and better performing, to note the error occurred again.

Even better would be the same detection across multiple PRs which suggests a build breakage has happened. When that logic is stable, the bot could create issues about build breakagees seen on PRs

I’ll take care of this one. I created the issue just to keep track of things!

Add "Deploy to Heroku" button to README.md

https://devcenter.heroku.com/articles/heroku-button

Function pullRequest has 45 lines of code (exceeds 25 allowed). Consider refactoring.

https://codeclimate.com/github/bluzi/travis-buddy/utils/pullrequest.js#issue_5aae5dcc685bd90001000032

Currently, there are many of async operations in the project, and unfortunately I didn't wrote it using the newer async/await syntax.
Since now it's fully supported by Node, I will find it must more easy to maintain if it'll be implemented using this syntax.

This is a great first issue, feel free to jump in.

As discussed previously it should be able to use something as https://github.com/xbmc/repo-plugins/blob/jarvis/travis-buddy-success-template.md

I think you mentioned it's blocked by travis itself, but this issue would be nice to track it.

Summary

The idea of TravisBuddy Reactions is to allow contributors to communicate with TravisBuddy using comments and labels.

@TravisBuddy stop

Commenting @TravisBuddy stop should force TravisBuddy to stop commenting on this PR.
routes/api.routes.js is the root of the API, every request to TravisBuddy API is directed through there, so that's probably the right place to query GitHub API for comments on the PR, and drop the request if one of the comments contains the phase @TravisBuddy stop.

Whether triggered by a merge or by a travis cron, an issue about the first red build would be useful

Function failureHandler has 26 lines of code (exceeds 25 allowed). Consider refactoring.

https://codeclimate.com/github/bluzi/travis-buddy/handlers/failure.handler.js#issue_5aae5dcd685bd90001000033

It would be nice if Travis Buddy showed more information in his comment when the Build evals to status: "errored"

Example PR for the current behaviour (will probably change soon so here to document what he says:

TravisCI finished with status errored, which 
means the build failed because something unrelated 
to the tests, like a problem a dependency or the build process itself.

Example Build where that happened to me

It should show at least the following important information:

error [email protected]: The engine "node" is incompatible with this module. Expected version 
">=4 <=9".
error Found incompatible module

Useful to see who isnt testing locally.

This is a feature request.

Let's say a build fails twice:

• Expected Behaviour:
  Travis Buddy only comments once and updates his comment. (Similar to how Codecov does this)
• Current Behaviour:
  What Travis Buddy does is comment 2 times on the pull request.

This way there will be less "spam" and with this featureI would disable the "on_success" flag.

This could either be the new standard behaviour or also enabled/disabled via a new flag. What do you think?

And btw: I really like the work you made here!

What type of work is left to get this working for private repos?

Summary

A Travis build has 3 main states: passed, failed and errored. Currently, we only handle the first two, we need to start handle errored too.

As BanzaiMan pointed out, errored means the build failed because something unrelated to the tests, like a problem a dependency or the build process itself.

How to resolve?

There are already handlers/success.handler.js and handlers/failure.handler.js, add another handler called error.handler.js, and implement it by looking at success.handler.js.
Then call it in routes/app.routes.js when the payload's state is errored, and make sure it creates a comment.
Also add a template to resources/messages/error/default.error.template.md.

You can test it by temporary changing test/samples/payload2.json's state to be errored, run npm test and see if it creates a comment. (The logging for this command should contain link to the pull request, if created successfully)

The template should be something like this, but feel free to be creative:

Hey @bluzi, 
Something went wrong with the build.

Should be free icon, under an open license (CreativeCommons)

Summary

The idea of TravisBuddy Reactions is to allow contributors to communicate with TravisBuddy using comments and labels.

travisbuddy-ignore label

Adding a label named travisbuddy-ignore to a PR should force TravisBuddy to ignore this PR and stop commenting on it.
Just like in #37, routes/api.routes.js is probably the right place to query GitHub and see if the label is presented in the PR, and drop the request.

Add resolvers and test repositories for other test libraries, such as:

• Karma
• Jest
• Jasmine
• ...

Also, we should add non-js libraries (Travis also supports Python, Ruby and more)

That's how the comment used to look like:

Now, for some reason, the log is missing:

The payload of the first build of a PR contains the PR data (pull_request_number, etc), but the later commits doesn't.

We need to find a way to connect a build to a PR without the PR number (maybe via branch name or whatever), so we can fetch the PR number and comment on it.

Hello, I am trying to make a success message which I am seeing from previous commits that it is implemented but I have not been able to make it work. The system works on failed builds and the comments are created according to the template on the root directory, but on success no message is made at all.

I would like to know if this is a bug, the feature is not finished being implemented yet, or I am doing something wrong. The name for the success template I am using is "travis-buddy-success-template.md" and the contents are the same as the template shown as the example in this repository. Obviously I dont have "on success: never" added in my travis and the default as shown in the Travis documentation webpage is "always".

Thanks for the help.

Summary

Currently, TravisBuddy collects the outputs of every test script executed by TravisCI, and adds it to the comment.
However, some of those scripts may have passed, so there's no need to add them to the comment.
A script has failed if its exist code is greater than 0, as 0 means success.

How to resolve?

The code in resolvers/simple.resolver.js is in charge on breaking the build log into scripts, the exist code of a script appears on the log in the bottom of each script, like this:
The command "..." exited with 1.

So just use regex to fetch the exist code and only add it to the list if it's above 0.

Similar blocks of code found in 2 locations. Consider refactoring.

https://codeclimate.com/github/bluzi/travis-buddy/utils/logger.js#issue_5aae5dcf685bd90001000036

Hi there, thanks for this great project!

I would like Travis buddy to create comments only when the Travis build is failing. The README suggests using on_success: never. However this does not work if there are other webhooks, as it will set on_success for them as well, which might not be desired.

For example my .travis.yml looks like:

notifications:
  webhooks:
    - https://coveralls.io/webhook
    - https://www.travisbuddy.com
  # I cannot uncomment this, as this would make Coveralls webhook not work anymore
  # on_success: never

Summary

@TravisBuddy should be able to pull configurations from a node travisBuddy in .travis.yml.
Example structure:

language: node_js
node_js:
  - '8'
notifications:
  webhooks:
    urls:
      - 'https://www.travisbuddy.com/'
travisBuddy: 
  templates:
    success: default
    failure: default
  insertMode: update

There should be no required fields (even travisBuddy isn't required)

How to resolve?

Add configuration.js to utils/, and make it a module that loads the configuration from the .travis.yml of a repository and query it.

In routes/api.routes.js, use utils/configuration.js to load the configuration from the requested repository (the repository name is available via data.owner and data.repo)

From there, every module should be able to query configuration by importing configuration.js and calling a query function.

I feel like he wants to fight me, not help me

Travis kills jobs when it doesnt see any activity like happened at:

https://travis-ci.org/coala/coala-quickstart/builds/417251612

This should give a different TravisBuddy message than when there is an error.

We recently changed our travis setup to include a build matrix, producing builds like this one

Unfortunately, TravisBuddy is able to get logs out of these kinds of builds, and leaves us with unsatisfying comments like this

Similar to #110 , but hopefully much easier.

coala/coala-quickstart#296 (comment) shows an example of the exact same build failing.

The reason is I am pressing rebuild on Travis jobs of that build, as their is one which is a bit fiddly and needs a few restarts. The same scenario will occur when Travis fails due to unrelated problems (http, packaging repo bugs, etc) and a restart is all that is needed.

I gave your travisBuddy a try here: acceptbitcoincash/acceptbitcoincash#699 (comment)

It outpout a ton of the log even though it was able to identify that the "rake" command is what failed the build. So why did it output so much of the logs?

I am working on a tool similar to travis buddy. Travis doesn't provide the pull request author name by default: https://docs.travis-ci.com/user/environment-variables/#Default-Environment-Variables

So, how does travis buddy figure out the user? (as seen in the screenshot)

ref: https://docs.travis-ci.com/user/languages/java/

If the log excerpt is not sufficient, or the log except is missing (#109), it would be nice to have a link to the log on Travis. This would help when looking at problems in old PRs where the travis build is no longer listed at the top of its PR list.

Hi,

So I have not used the bot yet but it looks like exactly what I am looking for. I was wondering though what happens if I have allowed_failure jobs and those fail but the others pass? Would I still get a notification? We have some validations we want to know about to make sure links are not dead or data in alphabetical order but they're not hard stops to being able to merge a PR or not. So, can we still get those to notify the PR so if they do them great, but otherwise its okay?

I do not see much documentation about how it handles jobs, would I need to handle all results I want to be notified about in the same job now?

Summary

Currently, what stops some repository owners from using @TravisBuddy is the noise and spam it does, since it comments a new comment every time the build fails.

The current mode will be append mode, where @TravisBuddy creates a new comment every time.
update mode will tell @TravisBuddy to create a single comment, and if a comment already exists in the pull request, it will update the comment with the new build state.

How to resolve?

Depends on #73

Query the insert mode from the configuration (#73), and modify handlers/success.handler.js and handlers/failure.handler.js so it'll create a comment only if the insert mode is append or if there is no comment, and update if there's already a comment and the insert mode is update. (The default should be append)

Hi,

I'm running Travis Buddy locally so I can try it out with some private repositories - I have everything wired up between Travis and the bot, so when a build fails, I get a comment added to the PR with the initial text at the start "Hey @, Please read the following log" etc, however the job content is missing.

I don't see any errors in the app logs. Do you have any suggestions on how I could debug this further?

Thanks!