Home/ Questions/Q 9173449
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T16:35:30+00:00

I am attempting to implemtent a way to deploy my compiled assemblies to QA

  • 0

I am attempting to implemtent a way to deploy my compiled assemblies to QA for testing. I have a number of repositories, each of which contain folders with projects and source code, and also a folder that contains the compiled assemblies produced from those projects. The image below is representative of my source repository workspaces.

Source repository

I also have a Development user group and a QA user group. The Development user group has full permissions to the source repositories.

I have tried a couple different ways to accomplish my goal, but have had little to no success:

I have tried creating a new repository called Assemblies, and adding Xlinks to my source repositories, and then denying all permissions to the QA user group for all folders and files in the source repository, with the exception of the Assemblies folder. However, when logged into Plastic as a member of the QA user group, I can still download all of the source files.

I also tried directly accessing the source repositories as a member of the QA user group, but I still have access to files that shouldn’t be available.

I am considering a check-in trigger. The trigger would add/check-in .exe’s and .dll’s into the Assemblies repository whenever they are checked into the main branch of a source repository. However, I’m not sure if I’m heading in the right direction. I don’t want to ‘reinvent the wheel’ if there is already preferred method or best practice that I should be employing.

Any suggestions or references would be greatly appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is my suggestion,

    Create a new repository in order to place all your binaries at output artifacts. In your central repository, the one that xlinks to the external ‘Third party‘ repository, create a new xlink to the new brand new “Binaries” repository.

    Now you will need to change your build system to copy all the binaries and artifact to this xlinked repository. A (cm ci -a) command will commit all the changed binaries, finally label the changeset with the “cm label” command, this label will help the QA team to test certain releases.

    Remove the view permission for the QA Plastic SCM group at the central repository and the “Third party” repository. Now the QA group will never know that there’s even a source code repository. The QA group will have a workspace working with the “Binaries” repository and your source code/repositories will be safely hidden and not accesible by this QA group.

    You can even have the “Binaries” repository in a external server/machine. So the source code is in devMachine:8087 and the binaries are in a different Plastic SCM server, for example “qaMachine:8087”. Using this methodology the QA Plastic users will be using a dedicated server.

    • 0