0

Situation:

Making commit, open pull request, and the test failing, then I'm making amend (git commit --amend and git push --force) for fixing this test. Test is definitely fixed, but after force push the build on drone is failing again with the same error.

New commits sometimes help, sometimes not. In a case, when new commits doesn't help, I don't know how to fix a problem, it can take hours or days of experimenting (creating new commits, pushing to the same branch, but still the same error, which definitely doesn't exists in commit, which drone builds or at least shows it) until drone stops to build some very old state(first commit) of files.

Is there at least any workaround, what I can do manually to fix this problem?

Removing cache doesn't help. Drone restart doesn't help.

Drone version: drone/drone:0.8.5

We use it with github, sometimes I think, it can be some problem of github cache, because the problem mostly disappears from them-self without any reasons. Because it is a pull request and may be there is error between commit hash it gets from webhook and actual changes, it fetches from github.

Dmitry Russ
  • 21
  • 2
  • 2
    Your description is very confusing. I am not sure what you are trying to describe. See https://stackoverflow.com/help/mcve for some hint on how to ask a question. – Urban Aug 07 '18 at 07:42

1 Answers1

0

As Urban commented, it's really hard to get a clear idea of the present problem, but let's start by clarifying a point which seems to be central here :

I'm making amend for fixing that test (sic)

If by that you mean that you already committed your work but did a git commit --amend to add some changes into that commit, BUT you already pushed to the remote repo, then your mention about a force push might make sense.

I'll just guess your remote refused your push because modifying a past commit in the tree is rewriting history and you can't do that by default, thus the needed subsequent git push -f.

Short answer would be : don't amend already pushed commits. Add new commits on top instead.

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
  • Sorry, will read and update my question tomorrow. And I will try to make a minimal reproducible example. "Short answer would be : don't amend already pushed commits. Add new commits on top instead." Not amending commits (or squashing or cleaning in other way) contradicts the philosophy of clean git history (there are many articles about it, for example: https://about.gitlab.com/2018/06/07/keeping-git-commit-history-clean/). I would say, it is not an option at all for us. We definitely will follow clean git history further. – Dmitry Russ Aug 07 '18 at 22:39
  • I used `git push --force` of course and remote has accepted it and I saw in a drone, that drone shows building new commit hash(which I pushed with git push --force), but it builds somehow something different, not a commit hash, which it show it building. Thats the most strange thing. Will try to reproduce with a test repository. – Dmitry Russ Aug 07 '18 at 22:49
  • It could be that the build server trying do a `git pull` and now it has conflicting commits because what it has locally is already overriden on github because of `--force`. Because of the conflict, the local repo is not updated with the new commits and it built the old commit on local repo. – DJ. Aug 08 '18 at 01:12