Originally posted by davidreich on June 02, 2025
I have found a previous feature request to improve password security when executing SessionCreator.exe (called from the GitLab CI/CD pipeline) but am unable to find a solution to encrypt the password so it cannot be viewed in .gitlab-ci.yml, in template yaml files or in the GitLab job results.
Is this possible with TestComplete version 15.69.139.7 x64 or pending in a future release?
Originally posted by scot1967 on June 02, 2025
I am not aware of any plans to improve password security in this way. I am a user like you however so I don’t know what SmartBear may be planning.
One solution I found involved adding a masked, protected variable in the GitLab project in Settings > CI/CD.
Info about SessionCreator and TestComplete…
https://support.smartbear.com/testcomplete/docs/working-with/automating/session-creator/index.html
… If you find my posts helpful drop me a like! 
Be sure to mark or post the solution to help others out and/or to credit the one who helped you. 
Originally posted by scot1967 on June 02, 2025
I found that feature request update as well. There was one up vote. Now there are two 
. Make sure to ‘Up Vote’ the request if you haven’t. It’s a 7 year old request so I am pretty sure it’s not planned to be added any time soon.
Originally posted by davidreich on June 02, 2025
I’ve used the /PasswordFile:“</path/to/password.txt>” option to at least not present the password or display it in the GitLab pipeline job results. This at least prevents it from a simple type of exposure.
Originally posted by Hassan_Ballan on June 02, 2025
I would not recommend passing the password via a file or command line, as this only obscures the password rather than securing it. Anyone with access to the pipeline configuration or job logs could still retrieve it, since your automation needs to decode or use it in plaintext at runtime.
For web testing, I’ve opted to rely on the browser’s built-in password management instead.
Another viable approach is to store the password in a TestComplete project variable of the “Password” type. This offers a more secure and manageable solution within the TestComplete ecosystem, especially if you’re integrating with source control and CI/CD pipelines.
If a response helped you out, don’t forget to Like it! And if it answered your question, mark it as the solution so others can benefit too.
Originally posted by rraghvani on June 03, 2025
Have you seen https://docs.gitlab.com/ci/pipelines/pipeline_security/ is there anything here that is able to help?
I’ve used Azure Key Vault for Azure Pipelines in the past, and I would assume there should be something similar for GitLab too.
Originally posted by scot1967 on June 03, 2025
I have found a previous feature request to improve password security when executing SessionCreator.exe (called from the GitLab CI/CD pipeline)
SessionCreator.exe RunTest /UserName:domain\\username /Password:$TC_PASSWORD /UseActiveSession /ProjectPath:"C:\\Path\\To\\Project.pjs"
The execution order would seem to prevent the use of a password variable set in TC since SessionCreator is called before TestComplete. Also, the password variables are not exposed outside of TestComplete. This is good practice to secure passwords needed for script execution within TC however.
Originally posted by scot1967 on June 03, 2025
There are encryption methods documented in this link that may fit your needs. This really seems to be a GitLab issue and not something that can be resolved by a change to TestComplete if I understand what I have read in the docs.
https://docs.gitlab.com/ci/variables/
Alternatively, use one of the native GitLab integrations to connect with third party secrets manager providers to store and retrieve secrets:
You can also use OpenID Connect (OIDC) authentication for secrets managers which do not have a native integration.
Malicious scripts like in malicious-job must be caught during the review process. Reviewers should never trigger a pipeline when they find code like this, because malicious code can compromise both masked and protected variables.
Variable values are encrypted using aes-256-cbc and stored in the database. This data can only be read and decrypted with a valid secrets file.
Originally posted by sean4311 on June 17, 2025
So I remember from years back that we actually did implement a feature like this. Not sure why it never made it to the documentation though. I’ll work with the documentation team to work on this. But regardless, let me show you how this can be done:
