Reusable GitHub Pull Request

[olblak]

Introducing a new parameter 'PipelineID' which can be used to group targets into one Github Pull Request, by default the PipelineID value is set to a full configuration checksum (source + conditions + targets) but it could be used to chain target from different configuration files.

The default value of 'PipelineID' changes the default behavior. By default, every target using SCM will push to the same branch that ends up being the same pull request on Github. This will significantly reduce the number of Pull requests generated especially in the situation we bump multiple times a value and we are only interested in the latest version update.

Another significant change for temporary branches is to use the format updatecli_<pipelineID> instead of updatecli/<pipelineID>, in the latter situation if the target git repository has already a branch name "updatecli" then it would fail.

Starting from this PR, we constantly update Github Pull request title and body with the latest information.

targets:
    chartVersion:
        name: jenkinsci/jenkins Helm Chart
        pipelineID: "15290729718975628322"
        kind: yaml
        prefix: ""
        postfix: ""
        transformers: []
        spec:
            file: charts/jenkins/requirements.yaml
            key: dependencies[0].version

• Need to be able to specify a generic pipeline title that could be used across the run for things like Pull Request Title

[olblak]

After a quick discussion with @dduportal, we concluded that we need a way to specify a pull request title as it's challenging to generate a title that totally represents changes done inside a pull request. Also In the current state, each target will update a PR title <target_1> -> <target_2>, then next updatecli run <target_1> -> <target_2>.

Another interrogation element that I had was, was it fine to automatically update a PR title/body when the content of the pull request evolves or if we need to track those evolutions, and we conclude that it wasn't the responsibility of updatecli to keep track of that. A pull request title/body must just reflect files changed.

Previously, updatecli would open a pull request per change like

• PR#1 Update Application to 1.1
• PR#2 Update Application to 1.2
• PR#3 Update Application to 1.3
• ...

Now we would just change PR

• PR#1 Update Application to 1.1 -> Update Application to 1.2 -> Update Application to 1.3