Your browser was unable to load all of the resources. They may
have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.
I am starting to work on adding proof build support to our builds. All my tests look good, but I do have some issues to have a successful deployment.
1. I want my existing configurations to be used for the official scheduled builds AND by developers for proof builds. However, after testing proof builds on QB3, I can see that running the same configuration would use the same workspace. However, I did notice that any build will revert any local changes in the workspace before proceeding so any official build would cleanup local changes left over from a prior proof build. That is good. However, I have my configurations set to SEQUENTIAL. I am assuming I need that so that if a proof build with local changes runs at the same time as an official build without local changes, that the local changes won't get mixed in with the official build. Please confirm my understanding of this. Anyway, because I apparently have to use SEQUENTIAL, then that will allow a proof build to block an official build. I don't want that. Therefore, I need to add a child node under my official build which can be used for proof builds.
2. Based on number 1, I now have extra child configurations under every one of my real official configurations. How can I give my developers access to run and stop proof builds to just those extra child configurations? As my previous post mentioned, I need separate perms for RUN_PROOF_BUILD and STOP_PROOF_BUILD. Having these extra perms, I can make a developer group and give that group RUN_PROOF_BUILD and STOP_PROOF_BUILD for the entire configuration tree. Without these extra perms, I have to specify hundreds of configurations of these extra child configurations to grant the RUN_BUILD and STOP_BUILD. It would be nice to have wildcard support in the group settings screen so that I can say any configuration that ends with "proof" should be granted to the developer group.
Any advice on these issues?
-
replies
3
-
views
1495
-
stars
0
-
What you are doing right now is correct: create separate child configurations for purpose of proof build to avoid mixing proof builds with your official builds. You may configure your proof build configurations to run concurrently (refer to http://wiki.pmease.com/display/qb30/Build+Concurrency for details) to get fast feedback to handle multiple proof build requests.
Adding extra permissions of RUN_PROOF_BUILD and STOP_PROOF_BUILD is not an option since proof build is only a repository level concept: some repository may enabled with proof build support while others are not. Until checking out a repository, QuickBuild does not know whether or not it is a proof build. I'd suggest to set up extra permissions for these child configurations via RESTful API programmatically if there are too many of them.
Yes, I can write a restful api program to do this, but it is a pain and I would have to continue to keep running it to keep everything in sync. We are constantly adding and removing builds and we can easily forget to update our permissions. It would be one more manual step to remember, when simply adding one line to the group permissions using wildcards like "root/**/proof" would take care of everything. Along the same lines, I have asked for wildcard support in the subscriptions section too so that developers could subscribe to "root/**/proof" build notifications, etc.
Using wildcard to setup configuration permissions will make it hard to maintain configuration permissions entry by entry in database. The consequence is that we may need to travel the whole configuration tree to do wildcard matching when determine permission of a certain configuration, and the GUI performance may drop dramatically.
