# Module signing secrets into container for CI? **URL:** \ **Category:** Module Development\ **Created:** [October 13, 2025, 4:35pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402 "2025-10-13T16:35:32Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [October 13, 2025, 4:35pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/1 "2025-10-13T16:35:32Z")
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](https://docs.gradle.org/current/userguide/build_environment.html) 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…) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [October 13, 2025, 4:51pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/2 "2025-10-13T16:51:23Z")
> [@justin.brzozoski](#): > > 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…) 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.](https://github.com/inductiveautomation/ignition-module-tools) ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 13, 2025, 5:08pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/3 "2025-10-13T17:08:05Z")
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. > ---
**Author:** ![Jonathan\_Meredith](https://avatars.discourse-cdn.com/v4/letter/j/a183cd/32.png) [@Jonathan\_Meredith](https://forum.inductiveautomation.com/u/Jonathan_Meredith)\ **Post date:** [October 13, 2025, 5:34pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/4 "2025-10-13T17:34:16Z")
I added a secret file to my ci pipeline. It uses GitLabs secure files and then I had to download the files. > **[Project-level secure files | GitLab Docs](https://docs.gitlab.com/ci/secure_files/)** > > GitLab product documentation. Pretty easy and secure. ---
**Author:** ![bmusson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bmusson/32/87530_2.png) [@bmusson](https://forum.inductiveautomation.com/u/bmusson)\ **Post date:** [October 13, 2025, 5:34pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/5 "2025-10-13T17:34:27Z")
> [@paul-griffith](#): > > GHA Yup, same thing here: > ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [October 13, 2025, 6:22pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/6 "2025-10-13T18:22:52Z")
Yeah, Github and GitLab and Bitbucket all have nice ways of dropping it in their respective CI definition files. 🙂 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! 😄 So, voila: ```python 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. 👍 ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [October 13, 2025, 6:49pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/7 "2025-10-13T18:49:28Z")
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 🤷 ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [October 13, 2025, 7:21pm UTC](https://forum.inductiveautomation.com/t/module-signing-secrets-into-container-for-ci/111402/8 "2025-10-13T19:21:42Z")
Yeah, some of my stumbling was my (unnecessary) insistence on making it so just running `./gradlew build` without any parameters would work.