Builds in Probo.CI

Every time you open a pull request or push code, Probo.CI spins up a live environment so your team can see, test, and review the changes before they ever touch production. That live environment is called a build. Builds can also be constructed from specific branches and commits - allowing you to go to a specific point in your software’s lifecycle to view items or test a commit that may at some point become a pull request.

1. How Builds Are Created

   Probo.CI creates builds automatically so your team doesn’t have to think about it:

   • Open or update a pull request - Probo.CI immediately creates a build and posts a link back to your PR so reviewers can click straight through to a running version of your site.
   • Branch based builds - select a branch and a commit (or hash) from your project page on the Probo.CI portal and it will spin right up.
   • Rebuild - need to re-run a build without changing your code? Hit rebuild from the portal and Probo.CI will spin up a new environment from the same commit. Your original build stays intact.

2. What You Get With Every Build

   Each build gives your team a fully functional environment tied to that specific commit. Probo.CI tracks everything about it:

   • Which pull request or branch triggered it
   • The exact commit it was built from, with a direct link back to your repo
   • Every step that ran, whether it passed or failed, and how long it took
   • A shareable URL so developers, QA, and stakeholders can all review the same environment
   • How much storage the environment is using

3. Your Build Environment Stays Up

   Unlike some CI tools that tear down environments the moment a build finishes, Probo.CI keeps your environment running. That means your team has as much time as they need to click through the site, test edge cases, and sign off on changes - without coordinating around a countdown timer.

   When you’re done, builds are cleaned up automatically to keep your storage usage in check. You can also pin a build to keep it around longer (see section 4).

4. Keeping a Build Around With Pinning

   If there’s a build your team needs to keep - a milestone release, a build a client is reviewing, or one you’re actively debugging - you can pin it. Pinned builds are never automatically removed, no matter how much storage pressure the organization is under.

   You can pin and unpin builds directly from the build page in the Probo.CI portal. Just keep in mind that pinned builds still count toward your organization’s storage, so it’s worth unpinning them once they’re no longer needed.

   See Disc Space Quotas for more on how storage is managed.

5. How Builds Fit Into Your Account

   Builds belong to a project (your repository), which belongs to your organization. Your organization’s subscription plan determines how many builds can run at the same time and how much total storage is available across all your projects.

   If your team is hitting the concurrent build limit, new builds will wait in queue and run automatically as soon as a slot opens - no action needed on your part. See Build Queues for details.

6. When Builds Are Removed

   Probo.CI manages build cleanup automatically so you don’t have to babysit your storage:

   • Automatic cleanup - when your organization’s storage limit is reached, older builds are removed first. The most recent build on each branch is always kept, and pinned builds are never touched.
   • When a PR is closed - Probo.CI is notified when a pull request is closed and begins releasing the associated resources.
   • Manual deletion - you can delete any build yourself from the portal whenever you’re ready.

   See Disc Space Quotas for full details.

7. Questions

   If you have questions about your builds or need help, please reach out to us at hello@probo.ci.