Support env variable to point jenkins.yaml location about configuration-as-code-plugin HOT 15 CLOSED

@ewelinawilkosz @ndeloof I think this a good one to start with. I'll start working on this tomorrow.

For the simple version, let's support URI's that can either be a file (locally), or some statically served file (I.E a gist). That should support most usecases i can re-use much from the implementation on Praqma's fork.

from configuration-as-code-plugin.

@ndeloof and @daniel-beck Ok. Let's do this then.

1. We scrap http and https support.
2. We instead take a path, it can either be a single file or a folder.
3. In case of a folder we scan for all .yml|.yaml files in folder and return those to be configured. In case of a file just return that.

Sounds ok?

from configuration-as-code-plugin.

I think it makes perfect sense.

from configuration-as-code-plugin.

there are two options then - merge changes from praqma/dev or reimplement manually
for now we want to support with env variable:

1. location on disk
2. location in git repository - raw file, or different solution, we can discuss it

in the future we can extend possible locations

from configuration-as-code-plugin.

Could we please get this right from the start and at least reject plain HTTP URLs?

from configuration-as-code-plugin.

@daniel-beck Sure no problem :)

from configuration-as-code-plugin.

I'm not a big fan enforcing https. This would make test/demo environment harder to setup, and for internal use I would expect many user will use plain old http.

from configuration-as-code-plugin.

If we focus on security, I would expect configuration to be stored as a k8s ConfigMap / docker Config / some comparable "injected" content. This "pull" approach is just for basic usage

from configuration-as-code-plugin.

@daniel-beck and @ndeloof Would a better approach to write some warning if you do use HTTP? Like a statement about that this should not be used in production?

I reckon im mostly gonna be use the path part of this feature, to start c-as-c with a configuration file outside my dev environment.

from configuration-as-code-plugin.

Then maybe we just don't need http* support and should avoid introducing it here.
Also, if we consider the other feature request to have multiple yaml files, better for this variable to point to a configuration folder.

from configuration-as-code-plugin.

see #34

from configuration-as-code-plugin.

Right i added my stuff for this to work with a very simple test. The big picture case in #34 is a superset of this task. I'll need to look up how k8 config maps etc work before i start comming up with suggestions on how this can be handled in a more generic and extensible way. But for now, it should be outside scope of this case :)

from configuration-as-code-plugin.

docker config = a tmpfs folder mounted inside container:

docker run --config source=jenkins-config,target=/config/jenkins.yml ...

container can then read configuration from /config/jenkins.yaml

k8s config has more option, simplest for us is a volume mount (same as docker)

  containers:
    - name: jenkins
      volumeMounts:
      - name: jenkins-config
        mountPath: /config
  volumes:
    - name: jenkins-config
      configMap:
        name: jenkins-config

from configuration-as-code-plugin.

Thanks @ndeloof and @MadsNielsen !

from configuration-as-code-plugin.

Closing this issue PR merged and accepted

from configuration-as-code-plugin.