The local builder allows the projects to be packaged locally. Here is an example of a simple use of this tool in the case of project packaging.
After following the “getting started for a developer” chapter, you will have at least one project with one application. The application chosen for the example is helloworld-binding.
Please be sure to have rp-cli installed, configured and connected to a local builder. Refer to local builder installation
$ rp-cli applications list ID Name Slug Project a3968638-58ae-41bd-9d9f-2e605fdceb87 Helloworld binding helloworld-binding my-awesome-project-1
This command shows your application
Helloworld binding in the project described before.
Steps to follow
Initialize the project
In this step, rp-cli retrieves the corresponding application in redpesk UI.
rp-cli local package init helloworld-binding --project my-awesome-project-1
Apply your modifications
As it is precised in the message after initialization:
The spec file 'helloworld-binding.spec' has been copied to '~/my_rp_builder_dir/gitpkgs/helloworld-binding' Please modify '~/my_rp_builder_dir/gitpkgs/helloworld-binding/helloworld-binding.spec' while working on packaging, only this specfile is used when running 'rp-cli local package run'
You can work on the spec file in your host here:
Run to do the packaging
Once spec file modifications done, rp-cli is ready to build the package locally. Just choose between native and cross packaging by select the target in the command line as below:
# If the target flag is not present, the default target is aarch64 rp-cli local package run helloworld-binding --target aarch64 --project my-awesome-project-1
rp-cli local package run helloworld-binding --target x86_64 --project my-awesome-project-1
Upload the new specfile
If the package was correctly built in the previous step, it is possible to upload the spec file in the UI using the following command:
rp-cli applications upload helloworld-binding --file-path ~/my_rp_builder_dir/gitpkgs/helloworld-binding/helloworld-binding.spec
Tips and tricks
If you want to make some changes for local use, as in this case, you can do it like this:
rp-cli local package run helloworld-binding --target aarch64 --project my-awesome-project-1 --shell
When you are in the mock, you can see its normally empty contents the first time:
<mock-chroot> sh-4.4# ls -R .: build ./build: BUILD BUILDROOT RPMS SOURCES SPECS SRPMS originals ./build/BUILD: ./build/BUILDROOT: ./build/RPMS: ./build/SOURCES: ./build/SPECS: ./build/SRPMS: ./build/originals:
That’s why it is necessary to firstly run the packaging with the -N option to keep the generated content of the mock inside it.
rp-cli local package run helloworld-binding --target aarch64 --project my-awesome-project-1 -N --shell
Once the build is finished, you can enter the mock and interact with it. It suggests to keep the same specfile or that you have to run the command again.
cd BUILD/helloworld-binding-1.0.1/ mkdir build && cd build cmake ..
If everything is correct, you will have something like:
<mock-chroot> sh-4.4# cmake .. -- The C compiler identification is GNU 8.4.1 -- The CXX compiler identification is GNU 8.4.1 [...] -- Generating done -- Build files have been written to: /builddir/build/BUILD/helloworld-binding-1.0.1/build
This is useful when you made some changes then do the local crossbuild very quickly:
<mock-chroot> sh-4.4# make -j [...] [100%] Built target helloworld-binding_build_done
This is the method for the crossbuild specified by the –target aarch64 flag but this is the same process for the –target x86_64 arch. As you understand how the mock for crossbuild works, you know that it is closed to the outside world as without any internet connection. If you want to add a custom or base-os Linux package to the mock, add the -install option for example.