@decidim/lot-core what do you mean by related repo? there's only 1 repo in decidim/decidim..

Also, how will this affect the acceptance of this PR?

@tramuntanal we've merged a lot of PRs since this PR was created, and none had this problem. I really don't understand what happens here.

what do you mean by related repo? there's only 1 repo in decidim/decidim..

I mean opening an issue to https://github.com/sj26/rspec_junit_formatter, which is the gem responsible for the formatting. Can you take care of it?

Hi @decidim/lot-core,
This issue is appearing in all new PRs wich originated from current master branch. Here is another example: https://circleci.com/gh/CodiTramuntana/decidim/1635?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

It is not specific to this PR so it think it is better that you take care of it, also because we don't know decidim-generators neither the rspec_junit_formatting gem.

@tramuntanal I merged current master and the job is green https://circleci.com/gh/decidim/decidim/109479

@oriolgual do we know why it's shown as "all ok" but "failed with errors"?
It's a rspec_junit_formatter bug? Did it happened on others executions?
I tried to reproduce it locally and couldn't do it :/

@andreslucena there was an issue with decidim-generators Gemfile.lock, so maybe we were using an old version that had some kind of incompatibility, I'm not sure either what was happening.

Hi @oriolgual ,
I was going mad. History for this branch has been rewritten, lots of code has been lost. I've event lost it in my local machine because I reseted --hard.

How did you commited your fix?
The ref to our last commit on this PR was: ca398d4 but it disappeared.
We're now trying to create a branch from it

Other thing that could be related is that you seem to be keeping a decidim fork and running circle builds against it. That seems problematic and it may cause problems because circle has builds with the same commit ids associated to different repos. I know I mentioned this in the past as a hack to alleviate your bottleneck problems in CI. I regret now though, it was really not meant as something you should be doing on a daily basis.

Maybe it's not actually related but could explain why only your branches hit this problem.

@deivid-rodriguez we explored this option, but came to special conclusion because they had other PRs from the fork with the tests correctly passing, and other PRs from this repo failing. The only pattern we found is that we (Codegram) rebase our PRs, while they add merge commits.

In the case of this PR, @oriolgual started rebasing but there were too many conflicts (because of the merge commits), so he stopped and added a merge commit. He found some conflicts in the generators Gemfile.lock (this job was the only weirdly failing), so we assume the error is caused by a chain of problems:

1. GitHub failing to recognize a conflict
2. CI failing to report a sane error message

@oriolgual can you confirm my explanation please?

@tramuntanal there are some conflicts now, and the tests seem to be failing (just so you're aware) 😄

@tramuntanal as @mrcasals says, I tried to rebase, then I realized it wasn't a good option and aborted it, then I just merged master to this branch and push it (I didn't push force). Here's the reflog:

@decidim/lot-core this PR is wrong now. We should go back to where it was and keep working from the new PR #3548 solving the problem at decidim-generators without overriding any of our commits.
This PR should then be closed.

@deivid-rodriguez we explored this option, but came to special conclusion because they had other PRs from the fork with the tests correctly passing, and other PRs from this repo failing. The only pattern we found is that we (Codegram) rebase our PRs, while they add merge commits.

What do you mean by "other PRs from this repo failing"? Is this problem being hit somewhere else other than with these specific commit sha1s?

We've seen this generators error in different PRs. Some of these PRs came from a fork, others came from branches from this repo (that is, not from the fork), like this one.

However the sha1's are available in the fork as well, so potentially it could still be the problem I'm mentioning. See for example: https://github.com/CodiTramuntana/decidim/commits/2b24bba553c51d73f67554081894c0b2945b6bab.

Pushing the same diff with different refs only to decidim/decidim shouldn't fail, I think.

Yeah, your explanation makes more sense than ours 😂

@deivid-rodriguez I'm going to extract a patch of the other branch and apply it to master to create a brand new branch and see what happens.
By the way, I'm not understanding which is the problem or the relation of the sha1 of a given commit..