Option to change the entire build status name

[irrandon]

What feature do you want to see added?

At the moment it is only possible to customize a part of the build status name.

gitlab-branch-source-plugin/src/main/java/io/jenkins/plugins/gitlabbranchsource/helpers/GitLabPipelineStatusNotifier.java

Line 111 in efb7780

final String statusName = GITLAB_PIPELINE_STATUS_PREFIX + GITLAB_PIPELINE_STATUS_DELIMITER + customPrefix + type;

It should be possible to change the entire name.

Upstream changes

No response

[robross0606]

Just documenting what "Customize GitLab build status name" does at all would be nice. What is the purpose of it? Can variables be used? The jelly documentation just says "Build status name custom part" and it isn't mentioned in the README at all.

I tried putting ${BUILD_NUMBER} in mine and it didn't work as I'd hoped:

It would be extremely useful if this feature did allow usage of special build variables because the Jenkins build number isn't tracked anywhere on the GitLab side that I can see. GitLab gets its own pipeline and job numbers that don't correspond.

[jetersen]

I agree with @robross0606 what is this suppose to do.

If you want to use ${BUILD_NUMBER} Jenkins has way to expand strings:

String expandedString = build.getEnvironment(listener).expand(rawString);

[TBBle]

If you put ${BUILD_NUMBER} in particular into the name, then wouldn't you get a new job created for each build? Then a failed build once would mark the MR as having failed forever, because a repeat build would be considered a different job. (We have a simlar problem locally that if the branch build fails and then the MR is created, the branch build is never run again, so the MR is considered "failed build" forever, even though later MR builds pass).

[cobexer]

If you put ${BUILD_NUMBER} in particular into the name, then wouldn't you get a new job created for each build? Then a failed build once would mark the MR as having failed forever, because a repeat build would be considered a different job.

External GitLab pipelines just aren't that useable... which is why we initially didn't implement such features (and I doubt it actually works in a usable way - but we don't use env expansion so that is not an issue for us)

We have a simlar problem locally that if the branch build fails and then the MR is created, the branch build is never run again, so the MR is considered "failed build" forever, even though later MR builds pass.

The changes in the original referenced PR fixed this by allowing all jenkins pipelines to report as just "jenkins".

The merged implementation however broke this again: f573169#diff-0ea998743baf3a63808a236f53b496a0888100bc6c64904bad9dac0f7a83b8e4 and f573169#diff-41435d3149a0400d381be79ff1f4ede8c2e48a0ffeed5b1ae6e860f0bdb30a3cR125

/cc @TBBle @mifitous @jetersen I suppose now that this implementation has shipped we need another boolean to disable adding the type at the end? Or does one of you know of a better option?

[mifitous]

Hi @cobexer
AFAIU the current implementation does not break the previous implementation, because you can either enable or disable "Overwrite full name" or not
if you want to use both environment variables and the default "jenkins" prefix, just set the checkbox to true AND use jenkins/${EnvVar}
OR
set it to false and use ${EnvVar}
Please let me know if you have any issue

[cobexer]

@mifitous with "overwrite full name" we can't stop this plugin from changing the name it uses to report the pipeline status to gitlab because it always appends the type to the name!

With "overwrite full name" set and the custom part set to "jenkins":

• for builds of Branches, Jenkins reports "jenkins/branch"
• for builds of Merge Requests, Jenkins reports "jenkins/mr-head"

Since a commit traverses these states:

• gets committed
• pushed to branch: Jenkins runs and reports a status to the commit as "jenkins/branch"
• MR created: Jenkins disables Branch job, creates MR Job runs a build and reports the status to the commit (with "jenkins/mr-head")

now if the first build gets aborted it reports cancelled aka failed as "jenkins/branch"
unless there is a new commit pushed to the branch while a merge request is open the MR will never be allowed to merge because the failed pipeline can't be corrected ever again.

that is why we added the option to control the full name Jenkins uses to report to GitLab so a mr build for the same commit can override a previous pipeline of a branch build.

And that is what changes to the implementation broke before they got merged and shipped.

Could I explain the problem in an understandable way?

[mifitous]

Hi @cobexer
I'll take a review at the changes compared to what you are describing here, and will try to find a way to implement a solution that covers our both needs

[Turiok]

Hi,

Thanks for the new feature. It'll be interesting to add it in the documentation too