Exposing visibility of build workspaces
Hello all,
Our developers/team leads have an interest in viewing what's included in a build done via the main development stream (i.e. work items + change sets). They build def'n they request the build via, is using a private workspace owned by a system user). They cannot view a snapshot, because the build is done in the private workspace, therefore, they cannot view the snapshot, therefore, they cannot see what's included in the build. Also, they have asked for the ability to compare builds, but cannot due to the problem above. I see only one option: Scope visibility of the build workspace so that they can see the contents. This is a simple fix, but is it the best way to provide this visibility? I read about "promotion", which sounds like what I'm looking for, but that requires extension platforms (which we do not have). Are there any other ways to provide developers and team leads a view into build contents without opening visiblity of the workspaces? Is this the best way to do it? Thanks! Chris |
Accepted answer
"Promote snapshot" was the old term for changing the snapshot owner. The action is now called "Change owner" to prevent confusion with a Z feature. Changing owners is certainly an option for you but the owner of the build workspace will be the one changing owners.
I don't see any harm in changing the visibility of your build workspace. The content is still protected by the permissions on the component. If someone doesn't have access to look at the component, the content can't be viewed. Users that shouldn't have access will be able to see the workspace but won't see any components in it. If you're still concerned, you can change the build workspace's visibility to project scoped. Chris Ryan selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Out of curiosity, are you not able to use the Jazz SCM build contributor? That would allow you to see the changesets and WI going into the build. That information would be attached to the build result and wouldn't require any change to the workspace.
Are you speaking specifically about the Jazz build user license?
The developers source code access, but unless I scope the visibility of the build workspaces, they cannot see the contents of the source code that was used to do the build.