Add a setting custom-ssl-cert (or similar name such as -body?) to give Git the custom certificate to verify the HTTPS connection.
The setting will be empty (in that case the entry should be ignored), or will contain the whole certificate in plain text.
(It may be possible to have base64-encoded string instead of direct plain text to avoid special chars and/or newline character, but I'm not sure it is necessary.)
This will be useful to write "portable" CI workflow definitions. The workflow can be run in multiple (ideally, any) Woodpecker CI services at the different network configuration, served by different admins.
Context
I'd like my CI workflow definitions to be host-agnostic as possible.
This is because I'll move my projects around, for example I'll host it simultaneously to Forgejo in my LAN, GitLab, and GitHub, in order to accept contributions and/or to keep the project less locked in.
If things that really depend on the CI systems' configuration are needed, it should be configured on the CI system side, not the workflow definition side.
So, I'd like to avoid the things below:
Mount host volume
such as /my-local-network-agent/root-ca.crt:/etc/root-ca.crt
Depend on an internal network resources
such as http://my-local-server/root-ca.crt
And additionally, HTTP servers in my network are using custom CA certificates (generated by Step CA) so apps should know them to verify SSL connection (possibly from Docker container, which won't know the certificate without the volume mount).
However, currenty custom-ssl-path and custom-ssl-url requires some kind of "host- or network-dependent" setup written in the workflow.
custom-ssl-path will need volume mount.
custom-ssl-url will need insecure HTTP request or the CA cert publicly exposed --- both are usually not very serious problem, but still not encouraged.
A new property to give CA cert directly, such as custom-ssl-cert, will solve the problem.
CI server will give the CA cert string as a global variable (preferred) or repository secret.
workflow definition will refer to them as custom-ssl-cert: ${MY_CUSTOM_CA_CERT:-}.
In private network, this will let git verify the custom CA certificate.
In public CI services, the string will be empty and this should have no effect.
In this way, the workflow can truly be "portable" among woodpecker hosts managed by different admins.
Summary
Add a setting
custom-ssl-cert(or similar name such as-body?) to give Git the custom certificate to verify the HTTPS connection.The setting will be empty (in that case the entry should be ignored), or will contain the whole certificate in plain text. (It may be possible to have base64-encoded string instead of direct plain text to avoid special chars and/or newline character, but I'm not sure it is necessary.)
This will be useful to write "portable" CI workflow definitions. The workflow can be run in multiple (ideally, any) Woodpecker CI services at the different network configuration, served by different admins.
Context
I'd like my CI workflow definitions to be host-agnostic as possible. This is because I'll move my projects around, for example I'll host it simultaneously to Forgejo in my LAN, GitLab, and GitHub, in order to accept contributions and/or to keep the project less locked in. If things that really depend on the CI systems' configuration are needed, it should be configured on the CI system side, not the workflow definition side.
So, I'd like to avoid the things below:
/my-local-network-agent/root-ca.crt:/etc/root-ca.crthttp://my-local-server/root-ca.crtAnd additionally, HTTP servers in my network are using custom CA certificates (generated by Step CA) so apps should know them to verify SSL connection (possibly from Docker container, which won't know the certificate without the volume mount).
However, currenty
custom-ssl-pathandcustom-ssl-urlrequires some kind of "host- or network-dependent" setup written in the workflow.custom-ssl-pathwill need volume mount.custom-ssl-urlwill need insecure HTTP request or the CA cert publicly exposed --- both are usually not very serious problem, but still not encouraged.A new property to give CA cert directly, such as
custom-ssl-cert, will solve the problem.custom-ssl-cert: ${MY_CUSTOM_CA_CERT:-}.In this way, the workflow can truly be "portable" among woodpecker hosts managed by different admins.