1

I have a github repository [1] (named "exo-cortex.github.io" that I want to use to make a static website on github). In it there are the hugo source files. There is also a git submodule [2] for the theme "archie", which I have forked, because I want to make some changes to it (i.e. KaTeX rendering of mathematical symbols). Through the command "hugo server" I can view the website locally where everything looks fine. Once I run the command

hugo -t archie

hugo compiles the project into a static website in the folder "public" [3].

I learned that through github actions I can let github do the compilation and deployment for me. In fact I get some kind of website, although without the theme and without the content. I have tried many times and it does not work.

Are there some common pitfalls with my approach? Is there a better way? For example I am thinking about working with 3 repositories [1-3] marked above. In this constellation I would have the main repo [1] under a different name (i.e. not exo-cortex.github.io) and 2 git submodules: [2] would stay as is and [3] (the folder "public") would be a second git submodule with which I would push directly to my github pages website. This way I would have to build the site manually on my local computer.

exocortex
  • 375
  • 2
  • 9

1 Answers1

2

The pitfall would be that github pages has very strict usability when it comes to public/commerical and other aspects. See link here.

This means you are developing with a methodology which will not be your final methodology in many cases. So is this a professional site? Is this going to be something you use for business?

(For example, if using amplify, a different pattern would be better)

This also depends on how many people are working on this or will (are you solo?) A pattern for instance would be to:

  1. Have 1 Repo: With the following branches:
  2. Branch-[main] which is what publishes - i.e. is what is "live"
  3. [branch - exo-cortexdev] - which is what you use for staging - you push to this, build, test and then pull to you "live" site - [main].
  4. [Dudedev] have your dev branch or however many for various developers or projects. Work with a local copy of [Dudedev], using for instance, github desktop, and use the local hugo server (hugo server-D) to test your updates and edits, push to your local branch, build to staging, then push to your "live" site (which would be main).

So in summary: Local Branch, test on your compu - happy - pushed to your branch in Github - pull to staging branch, build, test, ensure looks good on (amplify, github pages, whatever you are using), then go to main - which is live, external/published accessible by the world.

It's just an idea. Let me know. The above works because you've abstracted the build from the devs and ensured you can spin off whatever you want, still test it, and then deploy to your live when you're happy.

This would enable your workflow to shift to lets say, Amplify, or others.

I don't know if this helps, but it's a different point of view for reference.

Claude
  • 8,806
  • 4
  • 41
  • 56
Rogelio
  • 910
  • 5
  • 14
  • 1
    hey, thank you for your comment. I realized that I don't understand half the words you are using, so the problem might actually lay somewhere else. I managed to get it working through some other things and now I still have some problem somewhere else. But my original question was the result of a mix of many things that I didn't understand or unknowingly did wrong. So it is not a good question to help other people on stackoverflow. I will delete this question later and will post a more precise one later. But thank you for taking the time. Much appreaciated! – exocortex May 30 '21 at 09:18
  • Not a problem, I mean, how often is the confusion simply that one doesn't know what he doesn't know and isn't that the first step towards true wisdom? Best of luck! – Rogelio May 30 '21 at 18:54