build fail -- pulling from a default branch that is not 'master' -- PR welcome?

[amoodie]

Scenario

Project uses develop as default github branch, and merges into release for releases.

Problem

jekyll 3.8.6 | Error:  git '--git-dir=<path-to-repo>/deltarcm.org/_projects/DeltaMetrics/.git' '--work-tree=<path-to-repo>/deltarcm.org/_projects/DeltaMetrics' checkout '--force' 'origin/master'  2>&1:error: pathspec 'origin/master' did not match any file(s) known to git.

The repo default branch is hard-coded as "master" (Line 9). As best as I can tell, this variable (DEFAULT_REPO_BRANCH) is not touched until the call in git_shallow_checkout.

Solution

I have addressed this for local build by adding to the projects index.md frontmatter, a git_repo_branch, e.g.

site:
  git_repo_url: "https://github.com/DeltaRCM/DeltaMetrics"
  git_repo_branch: "develop"

which is filled with the default values set on Line 9, if it is not provided, with

unless project['site']['git_repo_branch']
  project['site']['git_repo_branch'] = DEFAULT_REPO_BRANCH
end

Finally, I've modified git_shallow_checkout to take the project['site']['git_repo_branch'] as a 3rd argument, and then use it in repo.xxxx calls.

Thoughts

• I'm not a ruby developer, so my solution may be a bit hacky. I'm happy to submit a PR if you'd like, for feedback, or allow you to implement a fix. let me know 👍
• do you lay out defaults somewhere else? An alternative approach to the project_data_reader module might be to lay out a Hash with default values at the top of the module, and then .merge! this with the hash configured by the project frontmatter for use throughout the OpenProjectReader class. This would be a larger refactoring though, I think.
• related to Smarter handling of fetching subprojects’ data #6
• love the theme, hope to be able to use it!

[ronaldtse]

@amoodie thank you for raising this and apologies for the late reply!

@strogonoff could you have a look here? Thanks!

[strogonoff]

Thank you for bringing this up, allowing to use different branch names is an important feature. The DEFAULT_BRANCH_NAME is even a bit of a misnomer right now, since for it to be “default” it should be customizable in the first place…

Going to push this feature in v2.2 this week.

Thank you for positive words!

[strogonoff]

@amoodie PRs are welcome in general, let me know if you would like to make one for this feature. In this case it’s obvious that branch name should be treated similar to DEFAULT_DOCS_SUBTREE. I don’t think it’d make sense to refactor defaults during the course of implementing this feature. If you don’t have a strong interest in implementing this yourself, I’m going to implement the feature per my previous comment.

[amoodie]

👋 hi @strogonoff, you can see the patch I implemented over here. I'm happy to PR this code, if you like it.

To be honest though, it's probably better for you to just implement the feature, and to implement it the correct way. I just hacked something together, knowing very little ruby. It's also very possible I missed a hook somewhere that would cause a break in the specs or software sections. I am not currently using those, so I couldn't test.