Module signing secrets into container for CI?

Module Development
1

Does anyone have a nice way to get code signing secrets into a Gradle container for CI building of their module?

Getting the files in is easy. Getting keystorePassword and certPassword in is stumping me. The stupid . in their project property names makes them unusable as far as I can tell via the ORG_GRADLE_PROJECT_xxx environment variables.

I thought I was going nuts but I eventually found this blog post where someone else is struggling with the same thing. His best solution would require I make one big GRADLE_OPTS environment variable with both passwords in it.

I feel like there must be a better way I’m missing.

(EDIT: Yeah, I could just make a script file in the container and use that as my launch point, using that script to pull the secrets into the command line… I’m probably overthinking this, but I still feel like it’s a weird weakness in the setup to not support the passwords directly from secret files or environment variables…)

2

Seems like an easy feature request or even PR: GitHub - inductiveautomation/ignition-module-tools: Tools that help in the creation and development of Modules for Inductive Automation's Ignition.

3

I did it via GHA in Ignition Extensions... I don't recall the env vars in particular giving me trouble, only the annoyance of having to b64 encode the files since GHA secret management only supports strings.

1 Like
4

I added a secret file to my ci pipeline. It uses GitLabs secure files and then I had to download the files.

Pretty easy and secure.

5

Yup, same thing here:

6

Yeah, Github and GitLab and Bitbucket all have nice ways of dropping it in their respective CI definition files. :slight_smile:

I should’ve mentioned that I was also trying to find a way to make it work with docker-compose so that our developers wouldn’t need to struggle with setting up development environments or having them get out of sync or conflict with other work.

But @bmusson had a subtle difference in his: he pushed secrets into the gradle.properties file in the home directory, which let them be used without conflicting with any gradle.properties in the source directory! :smile:

So, voila:

name: ignition-module-builder

services: 
  gradle-env: 
    build:
      context: .
      dockerfile_inline: |
        FROM gradle:7-jdk11
        RUN ln -s /var/run/secrets/gradle-properties /home/gradle/.gradle/gradle.properties
    user: gradle
    secrets: 
      - codesign-certificate
      - codesign-pfx
      - gradle-properties
    volumes: 
      - ./:/home/gradle/project
    working_dir: /home/gradle/project
    command: ./gradlew build

secrets: 
  codesign-certificate: 
    file: ./secrets/codesign.cer
  codesign-pfx: 
    file: ./secrets/codesign.pfx
  gradle-properties:
    file: ./secrets/gradle.properties

That works and I think it’s relatively clean.

Yes, that will re-build the damn gradle environment every time you let it close and re-start. If a developer is doing lots of iterations it would be more useful to run docker compose run gradle-env bash and then they can run gradlew over and over more efficiently. :+1:

1 Like
7

I mean, at that point you can also just pass arbitrary property overrides directly into the gradle command line, no need to stop in environment variables on the way :person_shrugging:

8

Yeah, some of my stumbling was my (unnecessary) insistence on making it so just running ./gradlew build without any parameters would work.

1 Like