search

jenkinsci / gitlab-branch-source-plugin

A Jenkins Plugin for GitLab Multibranch Pipeline jobs and Folder Organization
https://plugins.jenkins.io/gitlab-branch-source
MIT License
124 stars 94 forks source link

Pipeline status is not returning to GitLab when "custom script" is used in Build Configuration #395

Open prasad-clouduser opened 10 months ago

prasad-clouduser commented 10 months ago

Jenkins and plugins versions report

Environment ```text Paste the output here ```

What Operating System are you using (both controller, and any agents involved in the problem)?

PIC RHEL

Reproduction steps

  1. Used "Custom Script" in Mode field of Build Configuration in Multi Branch Pipeline.
  2. Ran the pipeline and able to execute it successfully and but pipeline is not returning the status.
  3. Pipeline status in GitLab in Pending state. Actually it should be showing as success but not in this case.
  4. Attached screenshot for reference. customScript

Expected Results

Pipeline status in GitLba should be showing as success and allow MR to merge with target branch.

Actual Results

Not returning pipeline status from Jenkins to GitLab. pipeline status in GitLab is in stuck state. PIC

Anything else?

No response

Are you interested in contributing a fix?

No response

fidelski commented 5 months ago

This does not only happen when using a custom script, it also happens when using a multibranch pipeline.

...
Triggered by GitLab Merge Request #140: handle-error-on-output => master
...
[GitLab Pipeline Status] Notifying merge request build status: RUNNING brmp/MR-140 #1: Build started...
[Pipeline] }
[Pipeline] // stage
[Pipeline] withEnv
...
[Pipeline] End of Pipeline
[GitLab Pipeline Status] Notifying merge request build status: SUCCESS brmp/MR-140 #1: This commit looks good.
Finished: SUCCESS

There is no [GitLab Pipeline Status] Notified after either the build started or the build finished.

[EDIT] Problem solved: The problem was the API key, it was not having sufficient privilege. Weird though, since I accidentally gave additional rights to "api" (like "read_repository" etc.). Creating a new API key with solely "api" scope solved the problem.