You should probably do both, in that if there's a non-web way to get
at release (or if not, is eventually exposed) then the UI block won't
stop the other mechanism. Can you make the release mechanism enabled
or disabled based on appropriate criteria, which would include a given
project currently building, and let the button drive off of that state?
On 19-Dec-08, at 01:16 , Maria Odea Ching wrote:
On Fri, Dec 19, 2008 at 1:22 PM, Wendy Smoak <[email protected]> wrote:
On Thu, Dec 18, 2008 at 8:05 PM, Maria Odea Ching <[email protected]>
wrote:
A couple of things came to mind... (I haven't tried it yet)
1. In the Configuration page, set Number of Allowed Builds in
Parallel to
a
value greater than 1 and save the changes.
2. Create a new Build Queue. You can create a few more if you want
but
you
shouldn't be permitted to create more than the Number of Allowed
Builds
in
Parallel you've set in the configuration.
What should happen if you go back to Configuration and reduce the
number of allowed builds in parallel below the number of queues?
I don't think we have this scenario covered in the implementation
yet. Good
catch Wendy :)
2. handle instances when a project is still building and a release
is
triggered
Just disable the Release buttons?
Yeah, I was thinking of blocking the release & returning an error
message,
but having the Release buttons disabled is way simpler & easier.
--
Wendy
Thanks,
Deng
--
Maria Odea Ching
Software Engineer | Exist Global | 687-4091 | Skype:
maria.odea.ching |
www.exist.com | Innovation Delivered
