Add variables on pipeline webhook
What does this MR do?
Add variables on pipeline webhook
Are there points in the code the reviewer needs to double check?
This is a pretty simple one liner
Why was this MR needed?
Pipeline variables are useful to create custom parametrised pipelines.
Variables can be used to track the purpose of a particular pipeline, and/or link to another higher level automatisation tool.
It is thus useful to get the list of variables in pipeline update events.
Variables are also not available in pipeline API: https://docs.gitlab.com/ee/api/pipelines.html#get-a-single-pipeline
There should be there as well, but this is another MR.
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added -
Tests added for this feature/bug - Review
-
Has been reviewed by UX -
Has been reviewed by Frontend -
Has been reviewed by Backend -
Has been reviewed by Database
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Squashed related commits together -
Internationalization required/considered -
End-to-end tests pass ( package-and-qamanual pipeline job)
What are the relevant issue numbers?
Merge request reports
Activity
marked the checklist item Changelog entry added, if necessary as completed
marked the checklist item Documentation created/updated as completed
Our practical example is slightly complex, I didn't want to confuse the description with our real example.
We have a bot that is connected to webhooks of gitlab, and is watching various events of our sw line components.
The bot is for example watching mergerequests, and is triggering pipelines of super projects that are including those components. The pipelines are triggered using the trigger pipeline API: https://docs.gitlab.com/ee/ci/triggers/#making-use-of-trigger-variables
Then when we get pipeline events, we can figure out from what component merge request this was triggered, and make appropriate external CI status.
With this method, we implement an Android/repo pre-submit workflow with gitlab-ci. Android is a beast with 700+ projects, and we don't want to maintain 700 .gitlab ci in each project to trigger the main integration project pipeline.
Thanks @tardyp - this sounds like a good idea, but I'll @bikebilly and @ayufan review since this relates to ~"CI/CD"
added ~2278654 Community contribution ~3260766 labels
I don't fully understand the need for having this and what value it brings, and what variables we effectively expose.
We seem to target only very specific use case: trigger variables, but I wonder if this is the right way to do.
@tardyp Would you mind to spend some time on describing how exactly the flow looks like and how you interact?
@ayufan I tried to summarize my main use case here: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18171#note_66784429 . not sure if you saw it.
Please let me know if that comment is unclear.
I can show you in details over appear.in or similar what we have built with gitlab-ci.
@ayufan , any feedback on my last answer? thanks
@ayufan Here are some excerpt of our CI architecture presentation (that we call Nestor), focussed on why we need variable in pipeline events:
I hope this helps to clarify the complexities we are trying to implement with gitlab-ci.
Thanks @tardyp give me a few days to review that :)
@ayufan Friendly reminder. Times flies! :)
@danielgruesso or @vbhupatiraju Can you help here if we want such functionality added?
