File credentials' secretBytes doesn't get replaced

CWP config sample (there are lots of plugins there, all of them have latest version):

bundle:
  groupId: "com.devops.demo"
  artifactId: "some-ci"
  vendor: "DevOps"
  title: "Configuration-as-Code demo"
  description: "Configuration-as-Code demo, produced by Custom WAR Packager"
buildSettings:
  docker:
    base: "jenkins/jenkins:2.164.3"
    tag: "some-ci"
    build: true
war:
  groupId: "org.jenkins-ci.main"
  artifactId: "jenkins-war"
  source:
    version: 2.164.3

plugins:
  #
  # required
  #
  - groupId: "io.jenkins"
    artifactId: "configuration-as-code"
    source:
      version: "1.15"
  - groupId: "io.jenkins.configuration-as-code"
    artifactId: "configuration-as-code-support"
    source:
      version: "1.15"
...
  - groupId: org.jenkins-ci.plugins
    artifactId: plain-credentials
    source:
      version: '1.5'
...

casc:
  - id: "casc"
    source:
      dir: some-ci.conf.yml

CASC:

credentials:
  system:
    domainCredentials:
    - credentials: 
      - gitLabApiTokenImpl:
          apiToken: ${jenkins_apikey_gitlab}
          id: jenkins_apikey_gitlab
          scope: GLOBAL
      - file:
          id: cert_devopsjenkinsgke
          filename: k8s.crt
          secretBytes: ${cert_devopsjenkinsgke_b64}
          scope: GLOBAL
...
  clouds:
  - kubernetes:
      credentialsId: ${admin_creds_devopsjenkinsgke}
      serverCertificate: ${cert_devopsjenkinsgke}

I am using K8S secrets to provide credentials to CASC. It works fine for any field (mentioned some of them in config) except of the file credentials’ secretBytes. Here is what I get in Jenkins startup logs:

May 16, 2019 5:58:07 PM io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator tryConstructor
INFO: Setting class org.jenkinsci.plugins.plaincredentials.impl.FileCredentialsImpl.secretBytes = ${cert_devopsjenkinsgke_b64}
May 16, 2019 5:58:07 PM jenkins.InitReactorRunner$1 onTaskFailed
SEVERE: Failed ConfigurationAsCode.init
java.lang.Error: java.lang.reflect.InvocationTargetException
        at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110)
        at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
        at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
        at jenkins.model.Jenkins$5.runTask(Jenkins.java:1096)
        at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
        at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.reflect.InvocationTargetException
...
Caused by: io.jenkins.plugins.casc.ConfiguratorException: credentials: error configuring 'credentials' with class io.jenkins.plugins.casc.support.credentials.CredentialsRootConfigurator configurator
...
Caused by: io.jenkins.plugins.casc.ConfiguratorException: file: Failed to construct instance of class org.jenkinsci.plugins.plaincredentials.impl.FileCredentialsImpl.
 Constructor: public org.jenkinsci.plugins.plaincredentials.impl.FileCredentialsImpl(com.cloudbees.plugins.credentials.CredentialsScope,java.lang.String,java.lang.String,org.apache.commons.fileupload.FileItem,java.lang.String,com.cloudbees.plugins.credentials.SecretBytes) throws java.io.IOException.
 Arguments: [com.cloudbees.plugins.credentials.CredentialsScope$2, java.lang.String, null, null, null, com.cloudbees.plugins.credentials.SecretBytes]
        at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:149)
...

So it is just not replaced for some reason. File representing K8S secret exists in container:

$ >>> kubectl -n k8s-jenkins exec -it jenkins-0 cat /secrets/cert_devopsjenkinsgke_b64
{LS0tLS1CRUdJTiBDRVJUSUZ ...

Spent some time investigating it, but with no luck. Could someone help me with that?

[timja]

here’s an example: https://github.com/jenkinsci/plain-credentials-plugin/pull/14/files#diff-189b0e5434d71b3eb4bc77dda6974e0fR12

[jetersen]

FYI might be helpful to know that JCasC is getting native support for variable expansion with base64 and file read. See #1408