We have a set of releases that we re-use on a scheduled basis (several times per day). These releases are never marked as deployed, we just create a new package and release it (thus automatically rejecting the prior package). We don't need to keep the entire history for such releases, and I suspect it is bloating the BuildMaster database. Is there a way to purge the rejected package information for this type of release?

Product: BuildMaster
Version: 5.8.3

Is there a permission I can set to allow for updating of release variables (without granting full admin privileges)? I have tried "Releases - Manage" but it doesn't do it.

Product: BuildMaster
Version: 5.6.8

Would you consider adding an option to prevent the second execution, since it could have negative consequences?

We are talking about different situations. I understand that multiple targets could execute simultaneously (and that can be desirable), but those are for a single "run" of a job. I'm talking about a scenario where a second "run" is started before the first "run" is finished.

Say I click "Create Package" for a release. The release enters the Build stage (which is the first stage in this scenario). The Build stage takes 15 minutes. While it is building, I accidentally click "Create Package" again for the same release. I don't want this second click to start the build process again.

This gets even worse if the release is deploying to an environment. A second instance of the same release trying to run at the same time as a prior instance could have all sorts of negative consequences.

Thanks Tod, but shouldn't the release itself know that it has a current execution that hasn't finished? For example, what should happen if a release is currently executing and I try to create a new package via the web interface for that release? I would expect the new package to be prevented from executing since there is a currently executing instance. (Anecdotally, I believe that was the behavior prior to 5.x release)

Thanks Tod. The bug ticket sounds like it will just prevent the error. Are there plans to create an API that will actually re-deploy to a stage?

We have jobs scheduled on a recurring basis. If a job runs long, the next scheduled job will still trigger, and will interfere with the currently running job. In our setup, it is not desirable for a job to trigger if the last execution is still running. Is this the expected behavior and if so, is there a way to prevent it?

Product: BuildMaster
Version: 5.6.8

I'm trying to use the endpoint "api/releases/packages/deploy" to deploy a release to an environment that has already received the deployment (analogous to "Re-deploy to Stage" option available via the screens), but I'm getting an error

Invoke-WebRequest : 2627141Builds_PromoteBuild28`Violation of UNIQUE KEY constraint 'UQ__BuildPromotions'. Cannot insert duplicate key in object 'dbo.BuildPromotions'. The
duplicate key value is (84564, Stage).

Is there a different endpoint for re-deployment?

Note that in this scenario, we don't need to rebuild the package, we just need to re-release the code.

Product: BuildMaster
Version: 5.6.8

Tod - thanks for the reply. We would definitely be interested in this feature in an upcoming release. Thanks.

Is there a way to suppress the warning generated when an artifact has no folders or files in it?

The log message is "There were no files or directories captured in this artifact."

Product: BuildMaster
Version: 5.5.1

In 4.9, BuildMaster handled this automatically and queued up any executions if there was one already running for an application. Was this behavior deprecated in 5.x?

We don't use URL triggers. This behavior occurs when the jobs are run manually (by clicking "Create Package"). It also occurs when we use Schedule Triggers.

We have multiple releases configured for an application. If one release is in progress, and a second release is triggered, the second release will run and possibly interfere with the first release.

Is there a way to prevent this, so only one release can run at a time for a single application?

Product: BuildMaster
Version: 5.5.1

When I create a new Schedule Trigger it will execute immediately if the time has already passed for the day. For example, if at 5pm on Monday I create a Schedule Trigger for Daily at 7am, it will trigger shortly after I set it up (i.e. Monday around 5:01pm). Is there way to prevent this behavior? The way it works now it means I have to set up new Schedule Triggers before the execution time (i.e. before 7am in the example above) which is decidedly inconvenient.

I understand that the service reviews scheduled triggers on a periodic basis, so the triggers won't always execute at the exact time set in the schedule - this is fine if it means that a job will run at 7:01am or 7:02am instead of exactly at 7:00am, but it would be helpful if there was a threshold after which the missed jobs would not trigger until the time arrives on the next day. Even better if this threshold was configurable.

Product: BuildMaster
Version: 5.5.0

Is there a summary page in the BuildMaster web interface that displays upcoming scheduled releases? For example, if I wanted to know all the scheduled jobs that will run tonight, where could I see this information?

Product: BuildMaster
Version: 5.3.5

When I Edit the "View Application" task, the checkbox for "Configure BuildMaster" under Administration is checked. Is this a bug? Why would the View Application task grant the ability to configure buildmaster?

Product: BuildMaster
Version: 5.3.5

I'm looking to create a variable that must be populated each time a new package is created. In BM 4.9, I believe these were called Build variables. What is the equivalent in BM 5.x and how do i create them?

The variable needs to be entered each time a package is created, and should not persist between packages. Ideally the variable would be listed on the "Create <application name> Release Package" pop-up window and would allow the user to enter a value there.

This variable is associated with a particular plan, but not a deployable.

Product: BuildMaster
Version: 5.3.5

Is there a way to prevent selection of a different pipeline when a release is created using a template? The template itself is working fine, and when the template is selected while creating the release the correct pipeline is displayed, but the user is offered the option to change the pipeline, which is undesirable in this context.

Product: BuildMaster
Version: 5.3.5

Alana - yes, thanks. Templates are working for what we need.

Alana - thanks for the response.

I had created multiple stages as you suggested, and it works, but it is clunky. All the plans in this context are for the building of a release, and the stages ended up being named Build1, Build2, Build3, etc. Using multiple stages means I have to apply and maintain any stage-level settings multiple times. Conceptually they are all part of the same step - the "Build" step - so it seems to make sense to have them in the same Stage.

The reason for having the separate build plans is so we can re-use them in different pipelines that may not utilize all the plans. In BM 4.9 we were able to share action groups between different deployment plans, but using Otterscript in 5.3 prevents this. Breaking up the plans into smaller pieces lets me isolate the code I want to re-use.