RoboMerge setup problem: cannot run LDAP, need alternative for testing

Development Pipeline & Plugins
, ,
1

Hello,

We are trying to set up RoboMerge for our Perforce workflow.

We created an image using batch scripts and connected it to our Perforce server. However, we cannot access the web page to test RoboMerge behavior with branch conflicts, because it requires LDAP.

We tried configuring LDAP by analogy with another product, but so far we were unsuccessful.

In the PDF included with RoboMerge, I found the following note:

Place your TLS pem file named robomerge.pem here. Note that if no ‘vault’ folder is found, RoboMerge will fall back to running on port 8080 over HTTP (see Watchdog.startServer in watchdog.ts) and no log-in will be required.

According to the logs, RoboMerge still opens on port 8877, but when I try to switch to port 8080, the page does not load correctly. Instead, the browser shows the error: “Sign-in over HTTPS required”. Interestingly, the static help page works fine, but the main sign-in and conflict pages do not.

I also noticed in the Docker environment variables that there seems to be a way to enable development mode. I tried setting NODE_ENV=development, but it did not change anything.

Question:

Is there a way to test RoboMerge without fully setting up LDAP — for example by running in a simplified/development mode where HTTPS and LDAP are not required — so we can at least test conflict resolution and general functionality?

Thanks in advance!

2

Just to let you know, as a general rule robomerge is provided as-is and not explicitly supported. While it is certainly being used by many external organizations, we unfortunately don’t have the capacity to document or provide support on it.

To your basic question I believe ROBO_DEV_MODE: “true” is the robomerge development mode that you’re looking for. NODE_ENV looks to only control some default levels of logging. You’ll also probably need to set ROBO_DEV_MODE_USER to the perforce user you want the default login to be used.

While it may not be useful to you, we do support both LDAP and OKTA login. OKTA is our internal mechanism for authentication, but we did leave LDAP in place and I’m not aware of any changes that will have negatively impacted its functioning.