Repository navigation
QNX builds fail inside DevContainer due to missing license and user setup #49
Description
Context
We are currently using a DevContainer for development, but QNX builds within Bazel fail because the environment is not properly configured for QNX licensing and user credentials.
In the CI build (which works correctly), the following environment variables are set and used to install the QNX license:
env:
SCORE_QNX_LICENSE: ${{ secrets.SCORE_QNX_LICENSE }}
SCORE_QNX_USER: ${{ secrets.SCORE_QNX_USER }}
SCORE_QNX_PASSWORD: ${{ secrets.SCORE_QNX_PASSWORD }}
run: |
mkdir -p /opt/score_qnx/license
echo "${SCORE_QNX_LICENSE}" | base64 --decode > /opt/score_qnx/license/licenses
Problem Details
- In the DevContainer, these environment variables are not set by default.
The QNX license file needs to exist at: /opt/score_qnx/license/licenses
- The current username inside the DevContainer is always vscode, not the actual system username — which might cause mismatches when setting up license paths or user-specific configurations.
What we need
We need a convenient and secure way to:
Make the QNX license and credentials available inside the DevContainer (e.g. via environment variables or a mounted secret file).
Ensure that /opt/score_qnx/license/licenses is created and populated correctly.
Handle the username mismatch between the local user and vscode inside the container.
Activity
opajonk commentedon Jan 30, 2026
Unfortunately neither me nor @lurtz have a QNX license at hand to develop or test this 🫤
lurtz commentedon Feb 23, 2026
we could make use of the solution used in https://github.com/eclipse-score/inc_someip_gateway/blob/e9a8d1b07e09d30fc84727cdef7908d29d61109c/.devcontainer/devcontainer.json#L7-L22
TimofteBogdan1900 commentedon Mar 2, 2026
i added on top of this
"
we could make use of the solution used in https://github.com/eclipse-score/inc_someip_gateway/blob/e9a8d1b07e09d30fc84727cdef7908d29d61109c/.devcontainer/devcontainer.json#L7-L22
"
this :
eclipse-score/inc_someip_gateway#41
or else it wont work for me
lurtz commentedon Apr 9, 2026
After giving this some thoughts I come to the conclusion that generic QNX support is hardly possible and has to be done on a per repo basis. The best we can do is to document that.
I took inc_someip_gateway/.devcontainer as inspiration.
First thing would be to rename the currently hardcoded
vscodeuser to the actual username running the host environment of the devcontainer. Because the devcontainer image is to be used by many users, this is not possible at build time in this repo. Thus this needs to be done in each repo using the devcontainer, because there the user starting the devcontainer is known.The next part is mounting the QNX license into the devcontainer. This requires existence of two files. We could add these bind mounts to the devcontainer, but then each and every repo using the devcontainer has to ensure in its
initializeCommands, that these files exist, even if the repo makes no use of QNX. That is not worth it.Document QNX setup and Dependabot workaround (#107)
github-actions commentedon Apr 15, 2026
🎉 This issue has been resolved in version 1.4.0 🎉
The release is available on GitHub release
Your semantic-release bot 📦🚀