GitHub Actions / Workflow process

Q1. When I add GitHub users via the settings panel in the app, What does this exactly do? I already have the dev team added to the main repo in GitHub so does this also need to be done?
Answer: When you install Staging Pro in your tenant, it creates a separate repository and separate branches; does not use your existing Git repository. When you add Git users in the ‘Connect GitHub’ tab, it gets associated with the separate repository created for Staging Pro.

Q2. Typically we use Dev branch where the developer first pushes, in the Staging Pro world should we consider staging-ENV to be our dev?
Answer: You can setup the environments, dependent on your company code flow process; Production and Staging if preferred. In this case, its ideal for codes to be committed and tested in staging before being moved to production.

Q3. We have some custom build actions, is there a way to run these via you or my flow should remain: PR merge [Develop] → Jenkins runs → Merge to staging-env,if pass.
Answer: Sure, as long as you make the code commit to the correct branch, it will show up in the History & Rollback > Code Deployment tab

Q4. How do you then like to promote code changes from staging → Integration and Production? Still use merges in GitHub to the named branches or via the UI?
Answer: The flow that is mostly used is Integration → Staging → Production. The reverse flow will also work, as long as there is no code conflict.