Hugo VS obsidian-export

name: 🚀 Deploy to prod # Will trigger the workflow on each push to the main branch on: push: branches: - main # Allows you to run this workflow manually from the Actions tab workflow_dispatch: jobs: # The first job will build the hugo site and upload the artifact build: name: 🔧 Build Hugo site runs-on: ubuntu-latest env: HUGO_VERSION: 0.111.2 steps: - name: Install Hugo CLI run: | wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \ && sudo dpkg -i ${{ runner.temp }}/hugo.deb - name: Install Dart Sass Embedded run: sudo snap install dart-sass-embedded - name: Checkout uses: actions/[email protected] with: submodules: recursive fetch-depth: 0 - name: Install Node.js dependencies run: '[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true' - name: Build with Hugo env: # For maximum backward compatibility with Hugo modules HUGO_ENVIRONMENT: production HUGO_ENV: production run: | hugo \ --gc \ --minify # We save the result as an artificat so we can use it in the next job - name: Upload artifact uses: actions/[email protected] with: name: release-artifact path: './public' # The second job will deploy the site to the FTP server using the artifact from the first job deploy: name: 🎉 Deploy runs-on: ubuntu-latest needs: build steps: - name: Checkout uses: actions/[email protected] # Download the artifact we just created - name: Download artifact uses: actions/[email protected] with: name: release-artifact path: './public' # This is the path where the artifact will be downloaded to - name: Deploy file uses: wlixcc/[email protected] with: server: ${{ vars.ftp_server }} username: ${{ vars.ftp_username }} ssh_private_key: ${{ secrets.ftp_password }} # or if you only use a password # sftp_only: true # password: ${{ secrets.ftp_password }} port: ${{ vars.ftp_port }} remote_path: '/var/www/app' # This will depend on your server local_path: './public/*' # This is the path where the artifact is located

Nowadays, it never has been easier to build and host a website for having any form of online presence. You don't even need a lot of web development knowledge. There are many tools and resources available that make the process easier than ever. One such tool is Hugo, a fast and flexible static site generator that allows users to create websites quickly and easily. In addition, deploying a Hugo site to a web server can be made even simpler through the use of Github Actions (assuming your code is hosted on github), a powerful automation tool that can be used to automatically deploy a website to a FTP server. In this article, we'll explore how to use Hugo to build a website and then deploy it to a FTP server using Github Actions, providing a step-by-step guide for those looking to get their website up and running quickly and efficiently.

The result of this historical evolution is that the world of static site generators has made amazing progress over the past few years and the Python ecosystem hasn't caught up with it. Nowadays there's a rich ecosystem of different options for static site generation, some of which lean more towards server side generation and simplicity (like Hugo) while others leverage Single Page Application frameworks like React.js or similar (like Docusaurus). On top of that, there are "headless CMSs" that can use some of these SSGs as a backend, offering a more sophisticated authoring experience while offloading the HTML output generation to a different component (like Decap CMS, Ghost, or Forestry).

We are going to use an application called Hugo to generate a static website. You could of course run Hugo on your own machine - but to flex your muscles in Azure, we're going to stand up a VM. You'll then be able to experiment with different ways to host this static website within Azure. First, create a resource group to house the authoring workload:

My blog is a static site hosted in AWS Amplify. There's no dynamic content on it at all. I push Markdown files to the main branch of my site repo in GitHub and Amplify builds it with Hugo. Hugo renders the Markdown as HTML and drops it in an S3 bucket behind a CloudFront distribution.

Hugo is not made for minimum viable blogs. Its advantage in performance only becomes important for bigger websites or blogs with thousands of articles. But especially for bigger websites it should be possible to auto-generate a good archive. However the developers of Hugo stubbornly refuse to fix this very important 8 year old issue: https://github.com/gohugoio/hugo/issues/448

If you don't feel like you need to create it from scratch (as in: if you want to have a static blog or website, and you don't mind if you didn't code every little aspect of it), I'd recommend using a generator like Jekyll, Gatsby or Hugo. And even if you don't directly use them, you can learn a bit on how they do this sort of implementation.

Hey thanks for looking :) hugo has a lot more moving parts, and a lot more dependencies [0]. bearclaw is written to be simple and easy to understand without instructions or learning any new paradigms about templating or frontmatter or other markup languages.

[0] https://github.com/gohugoio/hugo#dependencies

I had some expectations with lightweight alternatives to WP. Played some time ago with hugo (https://gohugo.io/), just wanted to set up a simple blog, couple of static pages, that i could extend any time I want.

I use this obsidian-export CLI program to convert prior to pushing to my repo and it's been working pretty well. This gives me a read-only version of my notes that is accessible from devices I don't have obsidian on (work laptop, for example).

If you limit your use of third party plugins, you can always use https://github.com/zoni/obsidian-export for this as well. I originally built it for exactly this use case (but now also use it as a crucial step in my pipeline to publish content to my own website)

It came from here! https://github.com/zoni/obsidian-export

If you add in obsidian-export as a build step (disclaimer: I'm the author), there is no need for people to change their Obsidian settings. Obsidian-export turns WikiLinks into regular Markdown links (and it flattens embedded notes) :)

Worth noting I maintain a project which does exactly this: https://github.com/zoni/obsidian-export

I have similar folders to [Oudwin](https://www.reddit.com/user/Oudwin/)... - dm - _inbox - assets - checklist - communications - research-reference - elements - sessions Additionally, I have had reasonable success using [obsidian-export](https://github.com/zoni/obsidian-export) to export my Obsidian vault to CommonMark. From there you have more options. I then build html pages using [mdbook](https://rust-lang.github.io/mdBook/) to control the information that is revealed to players. I am playing with using [MkDocs](https://www.mkdocs.org/) to see if it offers more control/flexibility. Regardless, the /elements folder contains all the lore chunks of the world including information I keep on the PCs. The /communications and /sessions folders can contain info with links to /elements that are revealed as needed. I make heavy use of transclusion ![[CoolThingFormAnotherFolder]] to keep it a bit more elegant and some custom styles are needed to make it how it look how I wish.

Shameless plug: obsidian-export. It will convert [[WikiLinks]] and ![[Embeds]] to plain Markdown (among a few other things) so you'll always have a way to go back if Obsidian doesn't work out the way you hoped.

So really you can't get what you want at all. You could try an external tool like this to export your notes to commonmark which is more widely supported. Ultimately if you are changing the path to files outside of obsidian (meaning they won't be automatically updated) you will break links. So maybe your best bet is to use wikilinks + an export tool.

If that's something you would miss, you could hook obsidian-export into a build pipeline to convert Obsidian-flavored markdown to regular Markdown (CommonMark, really).

While this would require an intermediate step, you could use https://github.com/zoni/obsidian-export to convert to regular markdown understood by pandoc in the mean time (full disclosure: I'm the author)