Abuse detected for my PRs and some commits

I’m getting “Abuse detected” for commits that I push to this repo:

https://travis-ci.org/lingthio/Flask-User/requests

What’s wrong?

Since you are not pushing commits too fast or anything, there must be some content that triggers Travis’ heuristics.

As such, you need to find out which commit first triggered the check.

This goes earlier in history than https://travis-ci.org/lingthio/Flask-User/requests has saved but the last build is for https://github.com/lingthio/Flask-User/commit/ae9cbcd38705d59e81a23f95de8ee61239c5a468. So the faulty change must be between that and the next commit that would have triggered a build.

There may also have been a change in Travis project settings (e.g. new envvars) that tips the detection off.
I deduce that by the fact that PR builds go successfully, and they don’t have access to secret variables.

1 Like

Hi @native-api!

I believe that Travis builds were disabled in settings for this project, that’s why the last build was in 2017. I enabled it again recently, but now Travis detects some abuse in my commits.

What can I do with this issue? How to force Travis to check my commits again? It’s definitely some kind of false positive.

I wonder on “why”, but the most important question is “how to fix” :slight_smile:

Also I’m not able to manually trigger a build:

Oh no! You tried to trigger a build for lingthio/Flask-User but the request was rejected. 

Only push builds were disabled, PR builds weren’t. You can see that in Travis CI - Test and Deploy with Confidence.

I explained what to do in my previous message, read it carefully. A developer with basic Git and HTTP knowledge should be able to take it from there.
(If you don’t have the necessary expertise and need everything to be done for you and/or a personal tutoring session to make sense of it, I can do that for a reasonable fee, PM me if you are interested…)

@native-api I’m not sure if I get you correct. Suppose I will find the commit after which Travis started to think that I’m an abuser. Then what should I do with this knowledge? Revert this commit or what?

Suppose, we have “faulty commit” somewhere in the repo, then why everything works just fine in my fork, which is identical to upstream?

Travis successfully build commits from another accounts, see: https://travis-ci.org/lingthio/Flask-User/requests. So I think that problem is not in the repo itself, not in “faulty changes”. Travis just marked me (@and-semakin) as an abuser in the lingthio/Flask-User repo, and now doesn’t start any builds triggered by me, but can start builds triggered by another person.

What can I do to fix it?

^^^

We don’t have any envvars configured in Travis, everything is default and clean. (Actually, I added some envvars yesterday, but nothing changed – I’m still an abuser, and the problem appeared before I changed anything).

The only ideas I’ve left is to re-check project settings – both here and at Github – for anything nondefault-looking or that may put undue strain on the CI. Also reset Travis integration according to Pushes won't trigger new builds anymore after the project has been inactive for a long time.

And after that, try building old commits that built successfully before (you’ll need to create branches at them for that).

If that doen’t help then you can be sure you are just banned. Since you’ve been ignoring abuse reports for so long, I reckon that’s possible.

Ok, will try to reset Travis integration. Thank you @native-api!

My first contribution to this repo was just 7 Nov 2019 :man_shrugging: before previous week Travis builds were disabled in project settings, so there was no chance for me to notice that I’m an abuser.

Issue solved. My steps to success:

  1. Start thread on Travis Community;
  2. Try random things and ideas, nothing helps;
  3. Wait for few days;
  4. Notice that Travis has support via e-mail (support@travis-ci.com), write to them;
  5. Issue solved in 10 minutes.

So if anybody stucks in the same situation as mine then just write to support@travis-ci.com and describe your issue. I believe that it is the most efficient way.

Any way, @native-api thank you for your assistance!

This worked perfectly for me, thanks. I WAS able to trim about 24 hours off the process by waiting only two days before noticing that Travis has email support.

Thanks again.