Analyze fastpages forking

[KonradUdoHannes]

Forking a fastpages repo does not work in the sense, that the fork will not be able to run the blog by itself.
The main reasons are probably

• Github actions don't have a deploy key that fits the fork
• URLs may mismatch

In order to make a workflow possible where users can fork the blog in order to contribute it would be good to understand everything that is required to change a fork into a working copy of the blog. This would benefit users that would allow users to contribute without having to use local docker/docker-compose tools.

The goal of this issue is to collect actions necessary to make a fork working.

In another issue we'll then look into automation (github actions) and documentation to make the gathered steps easier for users.

[KonradUdoHannes]

It is probably helpful to look at the initial setup pull request #1. Which describes how to setup deploy keys, which probably needs to be done for the fork as well.

The optional section also describes the custom domain setup (which correlaid-codes makes use of) This might need to be reverted for the fork. In the end the forked blog should be reached under <github_username>.github.io/correlaid-codes. And we'll have to ensure that it doesn't just forward to the original blog.

[KonradUdoHannes]

I tried the following

1. Fork
2. Activate actions and add ssh keys according to Initial Setup #1
3. modified _config.yaml and changed username to my username, url to https://<github_username>.github.io, base_url to /correlaid_codes
4. changed base_url in _action_files/settings.ini to /correlaid_codes
5. deleted the CNAME file

Steps 3-5 can be done in a single commit.

Afterwards the actions ran through without error and a copy of the blog was available under https://<github_username>.github.io/correlaid-codes

The further ToDos that I see here are

• Check that modification (styling/posts) of the fork update correctly on the blog
• look into how a pull request would be done

Thoughts on pull request

In order to make a meaningful pull request (with and added blogpost for instance), the modifications that make the forked blog work, must not be part of the pull request. A way to achieve this might be the following (not tried yet)

• Create a branch off the commit after forking and before the modifications described above
• use git rebasing to commits with content changes (blog posts/styling etc.) to the branch without adding the commits that made the fork work. I'm not sure what the best git commands are git rebase -i would probably work well but con probably not be directly transferred to a github action.
• create a pull request from the branch to the original repository