CI-friendly handling of Zowe usage in Uniwind (Expo EAS)

[ciacka]

Hi 👋
I wanted to share a small observation from using Uniwind in an Expo EAS build and get your thoughts.

When building Android apps on Expo EAS (CI/CD, headless Linux), the build can fail during the package installation step because a dependency pulled in by Uniwind attempts to use the system keyring (libsecret), which is not available in the default EAS build image.

In my setup, I worked around this by installing libsecret in a pre-install hook, which makes the package installation step succeed.

This made me wonder whether Uniwind could provide a more CI-friendly approach here – for example:

• detecting CI environments, or
• offering an explicit environment variable to let Uniwind skip or adjust its usage of Zowe-related functionality during install/build (if applicable)

This is just a suggestion / thinking out loud, not a complaint 🙂
I’m also considering reaching out to the Expo team to ask about adding libsecret to the EAS build image, but I wanted to check here first to see if there’s a preferred or more appropriate approach from your side.

Thanks for the great work on Uniwind 🙌

[jpudysz]

Hey! I'm not sure if we can pick dependencies based on ENV variable. We need this lib to store safely our JWT token for up to 180 days. Of course it's not applicable for CI/CD environments, but we have just one package for both.

Can you share your pre-install hook? Maybe we can add it to our official guide. Not sure if there is a better solution to this problem.

[ciacka]

Here’s how it looks on my side right now.

I’m using an eas-build-pre-install hook that runs only on EAS Android CI builds, based on Expo’s built-in environment variables. This makes sure it doesn’t run locally or on non-Linux environments.

#!/bin/bash
set -e

if [[ "$EAS_BUILD" == "true" && "$CI" == "true" && "$EAS_BUILD_PLATFORM" == "android" ]]; then
  echo "=====> EAS Android CI build detected – installing libsecret"
  sudo apt-get update
  sudo apt-get install -y libsecret-1-dev
else
  echo "=====> Skipping libsecret installation"
fi

I’ve placed the script in the project root for now, but the .eas directory might be a better location long-term, since it’s the official place for EAS-specific customization (workflows, hooks, etc.).
Make sure to run chmod +x ./pre-install.sh so it can be executed by EAS.

and in package.json

{
  "scripts": {
    "eas-build-pre-install": "./pre-install.sh"
  }
}

This works well for Android builds on EAS.
It’s probably not necessary for iOS builds, but I haven’t tested that case yet.

[jpudysz]

Thank you, I’ve already included your notes in the CI/CD guide. It should be published tomorrow.

[ciacka]

Quick update: I’ve opened a discussion on the Expo repo to suggest adding libsecret to the EAS Android build image:
expo/expo#42382

[ciacka]

Update from the Expo side: one of the maintainers responded and asked whether libsecret-1-dev would be sufficient, or if anything else is needed. @jpudysz – do you happen to know if there are any additional dependencies required beyond libsecret-1-dev?

On my end, I'm currently blocked by #316 (case-sensitive filename issue), so I won't be able to verify the full EAS build until that fix is released.

[jpudysz]

I have no idea as I don't build on linux.

Maybe you can patch-package quickly?

Fix is already deployed to main, but needs to wait for the next release.

[jpudysz]

Released with other fix. You can check now.

[ciacka]

I applied a patch in a meantime and ran an EAS Android build – it completed successfully with just libsecret-1-dev installed via the pre-install hook 🎉

[ciacka]

Released with other fix. You can check now.

Works like a charm

[Brentlok]

Hi @ciacka we've released a new experimental build that dynamically imports package that uses libsecret under the hood. Could you try uniwind-pro@1.0.0-beta.8-26012026 in your CI / EAS build without preinstalling libsecret? 🙏

[ciacka]

Confirmed it works – detached the pre-install hook and the build passed without any issues.
This is definitely cleaner than having to set up environment-specific hooks. Much appreciated! 🙌

[Brentlok]

Released in beta9 - https://docs.uniwind.dev/pro/changelog#january-27%2C-2026

[ciacka]

Hi again! I think this might be a regression.

I created a fresh expo project (56.0.11) using the latest Uniwind Pro (1.4.0) and tried building it on Expo EAS (Android). Unfortunately, the build is failing again.

Without any workaround I get:

Error: libsecret-1.so.0: cannot open shared object file: No such file or directory

I also tried the previous workaround from this discussion by installing libsecret-1-dev in eas-build-pre-install.

That changes the error to:

Error: [keyring] "glib" library returned an error:
"Cannot autolaunch D-Bus without X11 $DISPLAY"
Code: GenericFailure
error: postinstall script from "uniwind" exited with 1

This makes it look like the postinstall script is attempting to access the system keyring again during CI, whereas I understood the previous fix was intended to avoid exactly that.

For comparison, I also created another fresh project using the regular Uniwind (not Uniwind Pro), and the Android EAS build completes successfully. So at least from my testing, the issue appears to be specific to Uniwind Pro.

[jpudysz]

Hey @ciacka, thanks for the detailed report 🙏

Good news: nothing changed on the Uniwind side here. The postinstall in this package just prints a message and there's no keyring/libsecret code in it at all, and git history confirms it never did.

I think two things are stacking up:

1. SDK 56 bumped the EAS Android build image to Ubuntu 26.04. That newer/leaner base image doesn't ship the libsecret-1.so runtime, which is exactly your first error. On older SDK images it was likely present, so the problem stayed hidden

2. Your second error is the real tell though - with libsecret-1-dev installed it becomes Cannot autolaunch D-Bus without X11. That means our Pro postinstall is initializing the keyring at install time, which is precisely what the beta8/beta9 dynamic-import fix was supposed to avoid. So it looks like that lazy import regressed somewhere between beta9 and 1.4.0.

Thanks again for the thorough testing, I will keep you updated

[jpudysz]

I dug into this properly and reproduced it end-to-end.

Here’s what’s happening.

The postinstall has two paths:

1. CI/CD path

If UNIWIND_AUTH_TOKEN is set, it downloads Pro directly from our CDN and never touches the keyring

2. Local path

If UNIWIND_AUTH_TOKEN is not set, it falls back to reading your license from the system keyring, libsecret on Linux. This cannot work on a headless EAS image.

Your second error is the important clue:

[keyring] “glib”… Cannot autolaunch D-Bus

This only happens when the code reaches the keyring path, which means UNIWIND_AUTH_TOKEN was not set in the fresh project.

I reproduced all three cases in a headless Ubuntu 26.04 container, using the same base as the SDK 56 Android build image, and installing the real uniwind-pro@1.4.0:

Setup: no token, no libsecret
Result: libsecret-1.so.0: cannot open shared object file

Setup: no token, libsecret installed, headless
Result: glib/D-Bus GenericFailure

Setup: UNIWIND_AUTH_TOKEN set
Result: keyring is never loaded, installs from CDN ✅

Do you think it’s possible that the token is not set in CI?

[ciacka]

You're absolutely right – I checked our EAS build config and UNIWIND_AUTH_TOKEN was indeed not set in the fresh project. I must have carried it over manually in my previous testing and forgot to add it again when I recreated the project from scratch.

Added it to the EAS secrets / env config and the build now completes successfully without any workaround needed.

Sorry for the noise – this was a config oversight on my end, not a regression in Uniwind Pro. Thanks for digging in so thoroughly and confirming all three cases, that made it really easy to spot the mistake!

[jpudysz]

Thanks for the confirmation 🙌🏼

Sorry for the noise

No problem at all!