Remote Building

Remote builds are a faster way of triggering builds on YB as it would happen if you follow the expected steps: make changes, commit them, push them to a remote branch, and if the YML is correct, trigger a build in the CI.

So, effectivly, invoking yb remotebuild will bypass the change->stage->commit->push cycle by directly sending a patch made from local changes to the build service, that will dispatch a new build process.

Steps to remote build

To “remote build” is a way to cut down on test and build times. It’s a shortcut to see how the CI would build the local changes. It also offloads your workstation or laptop, so it could be used to continue developing amazing software.

If there is already a local work tree, cloned from a GitHub repository, the steps to accomplish a remote build are:

  1. Write down a correct .yourbase.yml, like described in Getting Started with YourBase, and verify the YML syntax:

    yb checkconfig
    
  2. Log in to YourBase and save the credentials locally. They get stored in ~/.config/yb/settings.ini. Run this command and follow the instructions:

    yb login
    
  3. Start the remote build by running:

    yb remotebuild [-dry-run] [-committed] [-patch-path <xxx.diff>] \
    [-base-commit <HASH>] [-branch <branch>] [-disable-cache] \
    [-disable-skipper] [-print-status] [-go-git-status] \
    [package target]
    

The available CLI flags are:

  • -dry-run: only does the preparation steps: check if the build service accepts build requests and generates a patch;

  • -committed: only consider local committed changes between HEAD and the merge base, the default behavior is to also consider untracked (honoring .gitignore), unstaged and staged changes;

  • -patch-path: saves the generated patch to informed file path;

  • -base-commit: uses this specific commit hash as a hint for the merge-base commit;

  • -branch: the CI will use this specific branch instead of the one checked out;

  • -disable-cache: disables cache acceleration;

  • -disable-skipper: disables skipping steps acceleration;

  • -print-status: Prints the result of git status used to grab untracked/unstaged changes;

  • -go-git-status: Use internal go-git.v4 status instead of calling git status, can be slow; the default depends on the git scm tool to be locally installed, but if it isn’t, the CLI will automatically fallback to the go-git.v4 library;

  • package target: build a different target then the default.

Using -dry-run together with -patch-path checks build permissions and saves the generated patch in the path informed.

Considerations

Remote builds are different from traditional CI event triggered builds, because the main purpose is to quickly check if the local changes are getting where the user wants them to be, and by that, ease the debugging by sharing the remote build log with other peers. So it’s possible to remote build public repositories, even if the user isn’t part of the GH organization (or person) that is the owner of that project. But trying, somehow, to build a private repo that isn’t enabled when YB GH App was installed, won’t work, the CLI will show up an error message asking for the user to fix that, by reinstalling of fixing the list of selected repositories.