Allow reloading configuration contents via POST (not from disk)

[sztomi]

Feature Request

I'm in the process of migrating our Jenkins installation to use Configuration as Code. We have some prior work in the form of a repo that uses Groovy to specify the jobs configuration (kinda like job DSL, but home-grown).

When this repo is changed, a build is started on Jenkins that reloads the jobs.

I would like to add the YAML CasC to the same repo and reload it during the same build. I found that it's possible to trigger a reload via a number of different ways (Jenkins CLI, API request). However, all of those ways assume a fixed location for the configuration.

Normally, our build jobs are checked out into a random workspace path which is cleaned up after the build is finished. We can work around this, but it would be nice to have a better solution. Hence this feature request. There is some prior discussion here: https://github.com/jenkinsci/configuration-as-code-plugin/issues/76

A POST endpoint that can directly load configuration would allow a natural webhook-build-update workflow to connect CasC to git. Additionaly, it would also be useful for administrators looking to change individual settings via curl.

Proposal

Add a new POST endpoint such that

POST JENKINS_URL/configuration-as-code/configure

takes YAML configuration that is applied the same way as if it was loaded from a file.

[jetersen]

Put your yaml raw url as the configuration and enjoy

[jetersen]

Read the getting started section on the Readme for details

[sztomi]

Thanks, I read the documentation. We have a private github repo that is not accessible without authentication. As far as I can tell, the URL field is not capable of doing that. We also store our configuration split into multiple files, which, as I understand is not possible to specify via the URL field, only the environment variable that sets the local path. Additionally, it's not possible to specify the currently built git SHA in the URL dynamically.

[jetersen]

Meh keep it simple point to master, create a small application that handles authentication for the git repo using a deploy token, not like one more container is gonna be the difference. 🤷‍♂

[sztomi]

@casz for a feature request, "change your requirements" is not really a relevant discussion point in my opinion. I can work around the issue just fine, the feature request is about upstream support to make handling this scenario better.

[jetersen]

The problem with adding these features into upstream in this case, is that it becomes more complex than it needs to be. Allowing to modify JCasC from a post body content sounds very dangerous when you consider the security implications. Not everyone uses https on their Jenkins so security is a serious concern.

Everyone has different wishes as clearly shown by your comments.

For me this is a issue I feel is best solved for each version of source control management be it GitHub, Bitbucket, Gitlab, Gitea and etc...

[jetersen]

I consider this issue an easy won't do because sending a http request with potential to leak credentials is a serious concern.

thoughts @oleg-nenashev @timja ?

[sztomi]

For me this is a issue I feel is best solved for each version of source control management be it GitHub, Bitbucket, Gitlab, Gitea and etc...

Can you outline how that would work?

Not everyone uses https on their Jenkins so security is a serious concern.

Sure, but this could be optional, just like there is already a post request that is optional. Not everyone is running Jenkins without https either. I'd argue that dismissing this because it can be insecure in an otherwise fundamentally insecure setup is circular reasoning (and also that no one should run Jenkins without https, but that's not relevant to this discussion).

[jetersen]

each scm handles viewing files as raw differently, same goes for authentication. So it becomes rather unmaintainable supporting the gitlab api or bitbucket api which

Just ask SourceLink devs how the work is going 😓

There was an attempt to add authorization header to the URL request but each SCM or any website again has different ways of handling authentication so it was never merged, mostly due to merge conflict, however I voiced my opinion with only supporting basic auth and token bearer header

[sztomi]

GitHub, Bitbucket, Gitlab, Gitea are all the same scm though?

[jetersen]

Ya if we want to support the git client which is also another complexity. However they have very different APIs and have very different ways of reading the raw file.

[sztomi]

So instead of all that complexity, how about the proposal in this issue? :)