-
Notifications
You must be signed in to change notification settings - Fork 618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Approved Merge Requests (EE-only) is not persisted #711
Comments
I too cannot disable "Approved Merge Requests (EE-only)". What does that setting do? Link to documentation saying what it does would be welcome. I was trying to disable it because of a hunch that it means to trigger a build upon an approval. Basically I was trying to troubleshoot #633 . Context |
Hello, I'm facing the same issue. Will there be any fix for this? |
I too am experiencing the same problem. I found the discussion #633 and followed it until I found this new open issue. Gitlab plugin version: 1.5.3 |
@jakub-bochenski @Argelbargel the change made from #664 is the cause of this bug. |
Sorry, I cannot reproduce that. Here is a screenshot of me changing this value. A bug that I can reproduce is connected to the Web form used to configure the job. |
@jakub-bochenski Are you saying you can change the value somehow, but not through the Web UI? If so, how? Are you using a plugin to keep track of project configuration history? How do you get to that view in the screenshot you shared? I'm just editing through the UI currently: We're using a plugin to backup our configuration via a git repo. I may be able to submit a change via that, but I think additional steps are required for the change to take effect. Really, I don't know how to control the configuration via direct file manipulation--IME there's more to it than meets the eye, maybe because of the aforementioned plugin. |
Looking through history, I do see a change to the config.xml:
but Jenkins is still building upon Approval, which is incorrect for our workflow. |
I haven't checked that, but it would be a separate issue from the incorrect display in Web UI. We use job-dsl plugin to manage the job configuration, that's why I haven't noticed the UI issue before. The change above was done via Web UI though, the screenshot comes from the JobConfigHistory plugin. |
I am also seeing this issue. Has anyone found any workaround? |
@williamzhao87 there is a PR fixing it linked above :( |
Any update on this issue? I also experience this - as soon as a MR gets approved, the pipeline gets kicked of again. In our workflow we run only want to run builds when pushes are done to the MR but not on approval. |
FWIW, as a workaround, I configured the Gitlab plugin (in the Jenkins job) to not build on the creation of an MR, which means we have to wait until approval for a build. (We have configured Gitlab to only allow merging with at least 1 approval + a successful build, i.e. a failed or pending build will block merging.) |
@shark-horse I'm curious how you configured Gitlab to block on Jenkins builds - is it through Gitlab CI? Did you also have to configure CI runners? |
@dskrvk What I was talking about in my previous comment was a config change in a Jenkins job, not a change in Gitlab. Specifically, I configured the Gitlab plugin in Jenkins to not build on creation of an MR: Notice that In Gitlab, I am using a Webhook that triggers on Merge Request Events (gitlabUrl/settings/integrations). I know it is sending information to Jenkins every time the MR is opened because, prior to disabling builds on opened MR's, Jenkins would build on opened MR's. Jenkins is simply ignoring that per the configuration in the Jenkins job. FWIW:
|
This was fixed/released in version 1.5.4 of the plugin, which should be available in the update center soon. |
Thanks! Can confirm that this has been fixed once I upgraded to 1.5.5 👍 |
Context
Problem description
The plugin doesn't respect a flag for
<f:entry title="Approved Merge Requests (EE-only)" field="triggerOnApprovedMergeRequest">
When toggling this setting and applying the change on refresh of the job, the toggle is activated again.
It should persist the toggle.
There are no log statements in the Jenkins log.
The text was updated successfully, but these errors were encountered: