Move scm directive to top level #388

olblak · 2021-11-21T19:13:01Z

Move SCM directive to top-level

Before this pull request, "scm" configurations are configured per resource at the source/condition/target level.
The consequence of that approach is that it generates a lot of duplicates.
Starting from now, each scm configuration is defined once at the top level and each resource (source/condition/target) references the scm using a scm id.

Due to how "scm" is a central component of updatecli, I had to differentiate scm "configuration" provide via a configuration, scm interface used by git and Github to manipulate git repository.
I also split pull request configuration into a top-level one as explained in fix #261 . I was refactoring the scm code anyway

Here is an example of a new configuration
.example

scms:
    updatecliRepository:
        kind: github
        spec: 
            owner: updatecli
            repository: updatecli
           # Skipping some parameter for better example visibility
source:
    updatecliVersion:
        kind: yaml
        scmID: updatecliRepository
        spec: 
            file: example.yaml
            key: image
           # Skipping some parameter for better example visibility

Test

To test this pull request, you can run the following commands:

go build -o bin/updatecli; ./bin/updatecli diff --config examples/updateCli.generic/githubRelease.tpl --values examples/values.yaml
./bin/updatecli show --config examples/updateCli.generic/githubRelease.tpl --values examples/values.yaml

Additional Information

In order to not break the existing updatecli pipeline configuration, I did the extra effort to convert "internally" the old syntax to the new one with the specificity that a GitHub scm would also automatically add pull request configuration.
I am still not sure if I want that to be the definitive approach.

In this pull request, I also decided the move the go packages source, condition, target, under the package pipeline instead of engine as I think it makes more sense to be there, next to scm and pull request.

Changelog

An updatecli pipeline configuration can now use two additional top resources, scms and pullrequests where they respectively allow to configuration sc's configuration and pullrequests' configuration.
Similiar to sources, conditions, and targets: scms and pullrequests expect a "map" of configuration.

The resources of type "source", "condition", "target", "pullrequest" now uses the key scmID to specify an scm dependency.
This avoids duplicating the scm configuration in every resource like it used to be.

Here is an example

scms:
  defaultSCMConfig:
    name: Defines github repository
    kind: github
    spec:
      ...

pullrequests:
  defaultPullrequestConfig:
    name: Defines github pullrequest
    kind: github
    spec:
      ...

sources:
  default:
    name: Get version from a github release
    kind: githubrelease
    sourceID: defaultSCMConfig
    spec:
      ...

SCM

Excepted that the scm configuration is now defined in its top-level configuration scms, parameters remain the same.

Cfr documentation on www.updatecli.io

| name | ✔ |-| Defines the scm name displayed in an updatecli pipeline run
| kind | ✔ | - | Defines the scm resource kind
| spec | ✔ |-| Defines the resource kind configuration

A scm of kind github can't define a configuration "pullrequest" as this is now living in its own place. Cfg the next section.

Pullrequest

| name | ✔ |-| Defines the pull request name displayed in a updatecli pipeline run
| scmID | ✔ |-| Defines the SCM that this pull request depends on
| kind | ✔ | - | Defines the pull request resource kind
| spec | ✔ |-| Defines the resource kind configuration

NOTE: At this stage, the only pull request kind supported is github.

Github

A GitHub pull request can be used to define how to create and configure GitHub pull request.
A pull request will be opened when needed. It also reopens a closed pull request if they are changes between the head branch and the remote one.

Parameters

Tradeoff

Potential improvement

olblak · 2021-11-24T08:25:35Z

In the current state of the pullRequest configuration, the pullrequests block expects to duplicate the same configuration as the scm one, like in the following example:

scms:
    repo1:
        kind: github
        spec:
           owner: updatecli
           repository: updatecli
           username: xxx
           token: yyy

targets:
    change1:
       kind: yaml
       scmID: repo1
       spec:
           ....

pullrequests:
    pr1:
        kind: github
        spec:
           owner: updatecli
           repository: updatecli
           username: xxx
           token: yyy
           labels:
                - dependency

Another option (not implemented yet) would be to have some sort of heritage, like:

scms:
    repo1:
        kind: github
        spec:
           owner: updatecli
           repository: updatecli
           username: xxx
           token: yyy

targets:
    change1:
        kind: yaml
        sourceID: repo1
        spec:
            ....

pullrequests:
    pr1:
        kind: github
        dependTargetsOn:
            - change1
        spec:
           labels:
                - dependency

In this second example, we retrieve the scm spec via "pullequests.pr1.dependsTargetsOn[0].sourceID" and then merge it with pullRequests.pr1.spec
If we go down that path then the pullrequest kind must be exactly the same as the scm kind which is GitHub in this case.

olblak · 2021-11-24T08:27:49Z

A second open question that I have is how to reference that part of the code in this pullRequest will be remove once we fully remove the deprecated to specify scm configuration.
Should I?
. Put a link to this pullRequest
. Create a new issue mentioning that some cleanup is needed and put that link in the issue
. Identify which releases version the current PR will land and put a link to the version

olblak · 2021-11-24T08:42:32Z

@dduportal I propose to target the milestone v0.17.0 with only this PR