Issue #19 new

Add a Force Rebuild option on swarms

Jason R. Coombs
created an issue

Sometimes, there are cases where one wants to rebuild and re-release the code for a swarm. Currently, that requires manually determining the tag, rebuilding the tag, determining the recipe, rebuilding with the recipe, and then re-swarming.

Much nicer would be a checkbox on the Swarm dialog which is 'force rebuild' which indicates to bypass the detection for whether a build and release are current and always rebuild and re-release.

Comments (3)

  1. Brent Tubbs

    A "swarm" is a particular abstraction over the primitives of build, release, and deploy, intended to cover the common use cases of upgrading an app's version or changing its config.

    A central idea in the swarming implementation is that two builds with the same tag are equivalent. I'm loath to complicate that in swarms.

    But I'm totally cool with some other abstraction to cover the less common case of wanting to rebuild all your apps with a new version of Python, for example.

    A parallel to Heroku might be useful. If they decided to start running on a new Python version, it would be their responsibility (as maintainers of the platform) to rebuild the slugs and make sure they worked with the new Python. In practice I doubt they'd ever do this. Instead, they provide more separation between the host and the app, so the app doesn't care if a system-level library changes. I want Velociraptor to get there. For that we probably need to move away from bind-mounting system folders into app containers, and instead provide system containers that ensure better isolation of dependencies. Docker is one way to do this.

    Is there a use case for this force-rebuild other than a changing Python version?

  2. Jason R. Coombs reporter

    Another use case is to do a rebuild of an app because its dependencies have been updated even though the primary source repo has not changed. For apps where the dependencies are hard-pinned, it would make no difference, but for apps that specify their requirements less stringently, it would allow those apps to be "refreshed" with the latest, best satisfaction of their declared dependencies.

  3. Jason R. Coombs reporter

    Another way this could be addressed - if Velociraptor's "release needed" logic were adapted to always use the latest build rather than any compatible build, then one could force a rebuild by first doing a manual build, then reswarming. That wouldn't affect the current Swarm UI, but would only affect the detection logic. Currently, if one does a manual build, it will not have any effect on a swarm that's already satisfied by an earlier build and release. Using the latest build, by contrast, would behave exactly like it does now where the presumption is there is only one build for a given tag, but for multiple would give preference to the newest instead of the oldest, which seems like a reasonable heuristic.

    Since in practice we do find the occasional need to force a rebuild for various reasons:

    • corrupted/invalid dependencies
    • cache invalidation or flushing
    • updated dependencies satisfying the tagged version
    • spurious errors in the build process

    It seems this approach would be a small adjustment for a useful behavior.

  4. Log in to comment