rMake:Workflow

From rPath Wiki

rMake --> Workflow

The following sequence shows a typical workflow using rMake during package or group development. The commands and other actions used at each step vary for each rMake build, typically depending on the packages and groups included in the build.

1 - Check out for updates
	The developer checks out a package or group from an upstream repository into an established local build environment. In this example, the developer has checked out version 1.1 of package example.
2 - Update in the local build environment
The developer modifies checked-out package or group in the local build environment. The developer may choose to include test builds to ensure the modifications build successfully prior to using rMake. For Conary-based systems, this includes modifying recipes, using the `cvc` commands to cook locally, and applying changesets to a test environment.
3 - Run rmake build
The developer runs `rmake build` with appropriate arguments and other options to build with rMake. The developer may use the options to take advantage of various rMake features. The actions in 4 through 7 below occur as part of the rMake build.
4 - rMake shadows from the original (upstream) repository
	rMake starts the build by shadowing the source component from the original (upstream) repository into the local rMake repository. In the example, example version 1.1 of the source is shadowed from the same upstream repository from which the developer originally checked it out.
5 - rMake creates and commits a changeset
	rMake creates a changeset from modifications in the local build environment, and it commits that changeset to the local rMake repository. In Conary, this is similar to committing a changeset to a repository with `cvc` prior to cooking the package or group in that repository. In the example, rMake generates a 1.2 version changeset of example from the local build environment and applies it to the local rMake repository.
6 - rMake uses build requirements to make a chroot
	rMake uses the build requirements in the package and group recipes to establish a temporary chroot on the local system. rMake will build in the chroot rather than on the local filesystem. This feature ensures independence between the local build environment and the environment desired for building the packages and groups. In the example, rMake creates a chroot with the build requirements for the updated example. The example shows that this includes obtaining resources from various repositories. In Conary, these build requirements are listed in the file example.recipe.
7 - rMake builds into the rMake repository
	rMake uses the contents of the chroot and builds into the rMake repository. When the build completes successfully, the chroot is deleted and the updated package or group resides in the local rMake repository. In the example, the rMake build results in example version 1.2.
8 - Run rmake commit
	After the rMake build is completed successfully, the developer runs `rmake commit` with the appropriate arguments to commit the rMake build to the original (upstream) repository. Unlike `cvc commit` in Conary, the rMake commit makes a clone while incrementing the version of the package or group in the upstream repository. Because rMake commits may include the building of multiple items, the commit is directed toward the job number generated by the rMake build. In the example, the developer runs `rmake commit` to commit the newly built example to the upstream repository from which the developer originally shadowed.