Git has an incredible branching structure so it only has to remember diffs when switching between commits. I consider this as constraint for this method of referencing, unless we have an ability to specified semver query with git commitīut I also have something in mind, maybe we could specified Commit attribute as plan as far as preventing wrong version-type errors, but it would also make invalidating (and deleting) pseudo-repos hard. Creating a shell script (containing the required pull commands and options) that each developer can run to update the robot code repository might be a good idea.The repo should be considered outdated manually, like a specific version of nuget package, the commit ID is like the version itself. Since the submodule does not update automatically when you pull changes to your main robot project you need to remember to run the git submodule update -remote command manually. Remember to keep the shared code version in sync if you have multiple developers working on your robot projects. Since the upload creates a zip package with the project contents, the zip also contains the submodule contents! However, when using Git submodules, you can still upload your robot to Robocorp Cloud using the upload functionality in Robocorp Lab, VS Code, or RCC. This means you can not use the Git repository linking feature in Robocorp Cloud for robots that use Git submodules. Robocorp Cloud does not automatically clone the submodules at the time of writing. The Git submodule strategy works for code-sharing, but there are some caveats. To update (pull the upstream changes to) the submodule contents, use the following command: git submodule update -remote Important notes How to pull the upstream changes to the submodule? See the Git submodule documentation for more information. To clone this project, including the Git submodule, use the following command: git clone -recurse-submodules -recurse-submodules option handles cloning the submodule. How to clone this example project, including the Git submodule? See the tasks.robot file in the repository for examples of importing and using the shared code. gitmodules file defines the path and the URL to the included repository: The shared Git submodule in this project was created with the git submodule add command: git submodule add shared ![]() The repository that includes the shared code repository was created using RCC and the standard Robot Framework template. The shared directory in the above file structure is the shared robot code repository included as a Git submodule. Here's what the file structure looks like in the project that includes the shared code as a Git submodule: shared 17dff6b The shared code repository is used as a Git submodule in another example repository. Whatever the repository configuration, make sure to test the shared code in isolation to make sure it works! An example of including the shared code using Git submodules One more production robot repository using the shared code.Another real robot repository using the shared code.A real production robot repository that includes the shared code repository as a Git submodule.A test repository that includes the shared code repository as a Git submodule.That test project would include the shared code repository as a Git submodule. The project documents its dependency requirements in the conda.yaml file.Īn alternative approach would be to set up another project for testing the shared code. Having the shared code as a normal robot project makes it easy to execute the keywords, call the library methods, etc., without unnecessary external dependencies. When developing shared code, you want to be able to test it. The shared keywords and libraries can be developed and tested in isolation. The project is self-contained and can be run as a normal robot project. The shared code project was created using RCC and the extended Robot Framework template. ![]() The shared robot code repository looks like a normal robot project repository because it is a normal robot project. The shared code repository looks like a normal robot project. This example robot code repository contains shared code that other robot projects can import and use. ![]() Let's consider this shared robot code repository: Perhaps it's a library that a third party developed or that you're developing separately and using in multiple parent projects." - Git documentation "It often happens that while working on one project, you need to use another project from within it. One option for code-sharing is to store the shared code in a separate Git repository and then include the code into the robots that need it using Git submodules. A separate Git repository for the shared code Please follow instructions in the documentation for sharing robot code. NOTE: This blog post contains outdated information.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |