GemFile and all folders that their names started with "_" vanish after deployment!

[mh-malekpour]

Describe the bug
My Gemfile and all folders that their names started with "_" vanish after successful deployment by bin/deploy --user command! I cannot see folders such as "_bibliography", "_data" and ... anymore. Why?

Repository: link

Screenshots

System (please complete the following information):

• OS: MacOS Ventura v13.0
• Browser: Chrome
• Jekyll version: 4.3.1
• Ruby version: 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin22]

[djherron]

Hi, I started using al-folio recently and had the same experience and pondered the same question. You should find all the original source files and directories on a new branch called source. The master branch has become your DEPLOY branch --- so on it you only see the files/directories corresponding to your website as generated/built by Jekyll.

I found an explanation for this behaviour by reading the bin/deploy script itself. It's just a shell script, so you can load it into any text editor and read the shell code.

You'll see that when you invoke the script with the --user option, it sets variables SRC_BRANCH="source" and DEPLOY_BRANCH="master". If the SRC_BRANCH doesn't already exist, it creates it (by, effectively, taking a copy of your current master branch) and switches to it. It then creates a clean DEPLOY_BRANCH by first deleting the existing one (ie your current master branch) and then re-creates a new, clean DEPLOY_BRANCH that is a fresh copy of your SRC_BRANCH (named source) and switches to the this new, clean DEPLOY_BRANCH.

It then invokes Jekyll to build the site on your DEPLOY_BRANCH.

Then the script deletes all the unwanted source files/directories from the DEPLOY_BRANCH --- everything that's not wanted for deploying your site and making it live. This is why your source files/directories disappear from the master branch. The script then also moves all of the generated files/directories Jekyll created within the _site directory up one level, out of the _site directory, and then deletes the (now empty) _site directory. The script then commits your DEPLOY_BRANCH, pushes everything to the DEPLOY_BRANCH on your remote repo, and then switches over to your SRC_BRANCH (named source).

So, the moral of the story is that, if you choose to deploy manually by running the bin/deploy script yourself, and you do so using the --user option (as recommended in the video by Spencer Rao), you have to do all your future maintenance on the branch called source.

For now, I've opted to take a different path. I started working with the 'automatic deployment' feature of al-folio rather than doing manual deployment by running bin/deploy myself. With 'automatic deployment', all I do is make my changes locally (on the master branch) and then push my changes to the master branch on my remote repo. The bin/deploy script gets invoked automatically as part of the 'push' operation. This auto-deployment operation is controlled by a GitHub action/workflow defined in .github/workflows/deploy.yml. It invokes bin/deploy without the --user option, which causes the script to use your master branch as the SRC_BRANCH and gh-pages as your DEPLOY_BRANCH. You can watch the push/build/deployment process happening by going to the Actions tab on your remote repo after pushing your changes to your remote repo.

This method is working smoothly for me now and I'm happy. But it was fiddly to get it working properly. Two fiddly things occurred.

First, the auto-deployment FAILED with a weird error message about a particular Liquid tag called 'twitter' not being recognised/supported. To get past that problem, I edited the sample blog post 2020-09-28-twitter.md and removed the two lines referring to this 'twitter' Liquid tag --- the two lines that were trying to load twitter tweets.

Second, the auto-deployment FAILED because it wanted a gh-pages branch (the DEPLOY_BRANCH) on my remote repo to exist already and I hadn't yet created one. But somehow, at some stage, a gh-pages branch was created by the deployment process itself. I never created one manually. After that, the auto-deployment started working smoothly.

I then tried an experiment of re-instating the twitter tweet loading lines that I had initially removed from blog post 2020-09-28-twitter.md and, to my surprise, the 'twitter' Liquid tag was now recognised and the twitter tweets were loaded just fine and everything was working smoothly. Happy camper. I don't have an explanation for the initial failure and the subsequent success re the Liquid tag 'twitter' --- perhaps it was connected with the initially missing gh-pages DEPLOY_BRANCH.

Hope this helps.

[mh-malekpour]

Thank you.