Git Shallow Clone Challenge
CODER, I challenge you in the name of internet glory! Can you solve the shallow clone problem?
Here's my shortened Stack Overflow post if you want to add to the conversation there.
A known issue with this action is that it can't handle building with shallow clones. That's why fetch-depth: 0 is currently required in the checkout step.
The problem is with merging changes from the source branch into the release branch. If we don't have a deep enough branch history for the source, release, and submodule branches, the merge fails because it doesn't have enough information to resolve the conflicts that arise (particularly conflicts merging the submodule directory). Until we find a way to solve this issue, we must always clone the entire history of a repo for this action to succeed.
I'd like to find a way to modify the action and achieve these goals:
- Remove
fetch-depth: 0to make shallow clones - Deepen the clone(s) history enough to make the merge work
- Continue with build and publish to the submodule
Well, some repos have a loooooooong history, and it's a waste of time and resources to always clone the full history when you might only need the 20 latest commits to make a new build. Being able to work with shallow clones would significantly cut down build time and build costs for some projects.
I set up a sample repo and sub-repo with 2 actions -- one that makes full clones, and one shallow. Feel free to play directly in those repos or make your own clones to tinker with.
Project Repo - https://github.com/aormsby/hugoBasicExample Submodule Publish Repo - https://github.com/aormsby/hugoPublishSubmodule
All I ask is that you don't change the 2 original workflows, 'Full Depth' and 'Shallow Depth', because they are a good 'source of truth' for others. If you need to make modifications to try something out, just make a new workflow.
If you run 'Full Depth', you can see the action succeed without errors.
If you run 'Shallow Depth', you can see the action fail with errors.
Important: You have to make a project change on the project source branch ('main') for the deploy action to attempt a build. If there are no changes (no new commits), the action will exit without doing anything. I recommend modifying, adding, or deleting things in the 'content' folder for something quick and easy. (I may create another workflow to do something like this automatically.)
- Set
fetch-depth: 150or something deeper than 1
This does not work. No idea why. 🤷♂️
- Fetching the history of all branches back to the last build commit hash
I tried for quite a while to get this to work. The action always saves the last build hash and last build time in the file hugo-deploy.dat after every successful build. I know I can use things like --shallow-since to fetch a deeper branch history back to those moments, but I've been unable to correctly deepen those branches of the main repo and of the submodule repo to support the merge from 'main' to 'release'. I'm sure there's more to be discovered here.
- Examining output of the
actions/checkoutstep.
I noticed the checkout config is a little different with fetch-depth on and off, and I've been wondering how much that limits what I'm able to do later in the Hugo deploy step. Not sure.
If you think you have a solution --
- Delete a post from the 'content' folder. Run the action with
full_rebuild: true. See if the post was correctly deleted in the published commit in the submodule. (I find that incomplete merges with shallow histories usually miss deletions.) - Share your code with me! Make a PR here in this project so I can see what you've got.
- Celebrate!