CI for pull requests about nitrocli HOT 12 CLOSED

I force-pushed on the branch, but it did not trigger a build.

Okay, thanks! I'll have to investigate some more. I'll create a second account and figure it out.

from nitrocli.

Thanks for pointing out that problem. I was under the impression it works. Pull request #16 that I created for the introduction of the feature certainly got checked through the pipeline (though, looking at it now it is not obvious whether that happened before or after the merge, but I definitely checked at the time that it was beforehand). Perhaps it's special because I created it? I'll try to get to the root of that.

from nitrocli.

Your pull request was on a branch in this repository, right? So maybe it wasn’t the pull request that triggered the build, but you pushing to the repository.

from nitrocli.

Yeah, must be something like that. Mind retrying? Just amend the top commit of your patch set with a different date or something and force push. I tried it with pull request #22 and everything worked fine. I changed a setting on the Github side.

from nitrocli.

I force-pushed on the branch, but it did not trigger a build.

from nitrocli.

My understanding of the problem so far is that a pull request does not actually create a branch in the repository the pull request is received in (i.e., d-e-s-o/nitrocli in that case). The way the Gitlab integration works is by mirroring the Github repository. But since the original does not contain that branch, neither will the mirror.

Github certainly sends an event about a pull request happening to Gitlab, it's just that Gitlab can't do anything with it, for lack of having the corresponding commit. So the notification presumably is just ignored.

Lack of a CI pipeline for pull requests is obviously a big problem, but I am not sure what I can do about that. I may look for other repositories using the same mechanism and check whether they have a solution.
The only real solution I see is moving away from Gitlab. A direct integration with Travis does not have this problem, as it works differently from what I understand. But there are reasons why I went with Gitlab to begin with. Sigh.

from nitrocli.

The only real solution I see is moving away from Gitlab.

The other alternative, of course, is moving everything to Gitlab. But I don't like that either ;-)

from nitrocli.

I have excellent news on this front! I found a way to trigger the pipeline on pull requests. I just tested that functionality with pull request #26 and the pipeline was triggered correctly. The glory details to the approach and the code can be found in the github-pull-request-mirror repository (sadly I could not implement it in Rust right now, but it's better than nothing :)).

There may be a couple more changes happening in the background, but I hope this service runs in a stable manner. Let me know if there are still problems.

from nitrocli.

Great, thank you! :-)

from nitrocli.

One small issue: The summary for the clippy job does not show the actual error. Might have to do with stdin/stderr. No big thing, but could you check if there is a clippy option to fix that?

from nitrocli.

I was under the impression that's just because Gitlab simply only shows the last nine lines in that view, and the relevant information does not happen to reside in those. I tried to cut down the remaining boilerplate being printed after the failing command, but was not successful. clippy has very few options and nothing to influence that. I believe that is a cargo thing, actually (you can see similar output on a compile error). cargo honors the RUST_LOG variable but it seems impossible to suppress this noise.

Ultimately one thing that should work is:

clippy ... 2>&1 >/dev/null | head --lines=-8

Not sure if that is really a great addition, though.

from nitrocli.

Ah, okay. Better leave it as it is then. Thanks for investigating!

from nitrocli.