We can get around this by passing a personal access token to GitHub's checkout action and telling it that we need to pull submodules recursively.Īn example of this action can be found below, and is actually what I use in my site's repo. Unfortunately, this doesn't quite work out for two reasons we won't have write access to the repository and we won't be able to clone private repositories. Of course, the simplest way to do this would simply be to recursively clone the repository using GitHub's checkout action, to run git submodule update -remote and then git push the changes back into the repository. The first step is to create a GitHub Action in our repository that updates submodules for us. GitHub Actions allows you to trigger commands on arbitrary events using the repository_dispatch event. (although unfortunately it won't quite get us all the way there) Great, so now we know update our submodules to the latest remote commit (huzzah!), but I want to push to one repository and watch the other repositories automatically update to track that commit (instead of requiring me to run a command). gitmodules file, which can be used to iterate through the submodules and pull down the latest versions.Īnother option is using the git submodule foreach command to update the submodules by fetching the remotes and then checking out latest commit, which has the disadvantage submodules not (by default) being checked out branches, and instead is checked out to commits.īoth of these options are obviously not particularly ergonomic to work with, and so git introduced the -remote flag to git submodule update to tell it to update to the branch tracked on the remote instead of the local repository. This makes life a little more difficult - how can I easily update submodules without having to specifically know the remotes, branches or location of all of my submodules?įirst, all of the submodules have their remotes and locations (and optionally branches) stored in the. You see, submodules are tied to a specific commit, and running a command like git submodule update (which you'd think updates a submodule to the latest version) only checks out the submodule to the same commit as what your local repository already has stored. I only recently moved to using the same codebase for the theme of my site and blog, which has both made my life easier and caused me a great deal of heartache - and almost all of the heartache came from git submodules. I personally use submodules in the repositories for a wide variety of uses.įor example, my research project uses a submodule to track the latest version of the codebase that I am modifying so I can write patches to match against those versions.Īnother example is my site, which has a bunch of submodules to track various things which get published there, from my resume and my research project, to the theme that I use for both my site and this blog. I know that the mono-repository is in style at the moment, but git submodules are a fantastic (and probably over complicated) tool for being able to store components of a git repository that may need to be kept used, but separate.įor example, you may need to track a specific upstream version of another repository that isn't controlled by you or your organization for use in your repository, or you might want to mix repository visibility or share some code between different repositories that need to be separated. Still, it would be neater if we did not need to use the intermediate 'GitHub.' projects.Tom Almeida Automatically updating git submodules using GitHub Actions Most developers on the team will fetch the main repo + xlinks straight from Plastic Cloud and never notice the GitSync usage. The main project contains xlinks to the 'GitHub.' projects. Programmers who want to propagate updates from GitHub to Plastic Cloud will use GitSync on their local Plastic server to replicate changes from GitHub to their local Plastic server, and then they push the updates to 'GitHub.' repo in Plastic Cloud. It is feasible (but clunkier than we would like) to have the developers who modify/update the Git repos do local changes & use local Plastic servers.įor each GitHub repository with an URL like '', we create a mirror repository in Plastic Cloud, named 'GitHub.'. The current GitSync feature requires every developer to make local changes on his/her workstation, plus use local Plastic servers. A small number of developers will occasionally update the submodules/xlink references to newer versions or do real work within the sub-repos. Most developers on the team will just pull down the whole repository + sub-repos and proceed to work in the main repository. I am looking at something similar, but on a smaller scale: Unity project, ~15 devs, workspace at ~4.5GB, core codebase is in Plastic (Cloud) but we want to pull in GitHub repos as submodules/xlinks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |