[Milestone] v4

[jcbhmr]

I've recently made a lot of changes that I'd like to incorporate into a v4 release. There's no risk of breaking changes because nobody uses the @master tag! #23 It's awesome that good versioning practices are so prevalent! ❤️

Here's a summary of some of the changes that I'd like to incorporate into this repo:

• Use with: instead of env: like all other actions Use with inputs instead of env #27
• No longer using rsync to put files into a git repo. Instead, we use $GIT_WORK_TREE to move the git worktree to the files, not the files to the git worktree! 😲 Drop rsync dependency #31
• Use a non-Docker based method for building the action. Use a non-Docker based method for building the action #32
• Add a test.yml GitHub workflow to make sure that the action works in PRs! Add testing workflow for PRs #33
• Add a dry-run: true optional flag for testing purposes #34
• Add a demo wiki test.yml to use #35
• Use a strategy: clone|init switch to either a) add a commit to the existing repo or b) create a single commit and force push that. Use a strategy: clone|init switch #36
  • Some people might want the semantics of a single deployed commit instead of a continuously stacking uncontrolled git history. More options are better.
  • For large image blobs (popular in some auto-generated wikis!) the git history gets bloated by so much non-diff-able .jpg 10MB files that it becomes slow over time. Force pushing a single commit solves this.
• Keeping strategy: clone as the default is perfect.
• Add a github-server-url option #37
• Use gh auth setup-git to manage git credentials. Use gh auth setup-git for authentication #38
  • Dealing with tokens seems complicated. Delegating to an official tool that just needs a GITHUB_TOKEN var set is great!
  • gh is ALWAYS available on runners. Windows, macOS, and Ubuntu.
• Add a note in the readme about Initial conversion of MD hyperlinks to MediaWiki #9 Automatically transform in-source links to in-wiki links #8 Clarify scope #26
  • Preprocessing links to make them accurate in both GitHub source view and GitHub wiki is a good idea! It's a great fit for another action. And there's already an action that fits this: https://github.com/marketplace/actions/strip-markdown-extensions-from-links-action
• Added an update-tags.yml action to auto-create v4 tags from v4.0.0 releases and keep them always updated. There's an official action for this! When you release a vX.Y.Z tag it changes vX to point to it. Auto update vX tags when vX.Y.Z releases are made #39

[jcbhmr]

I know this is like 2 months late from when I originally got involved with github wiki action stuff. 😬 But hey, better late than never!

[jcbhmr]

sidenote: consider renaming master to main to be "hip" and "cool" 😆 https://github.com/github/renaming

[jcbhmr]

todo: @jcbhmr -- add the improvements from the readme https://github.com/Andrew-Chen-Wang/github-wiki-action/blob/jcbhmr/README.md to this list to do and track issues and open prs for that stuff

[Andrew-Chen-Wang]

@jcbhmr Thanks so much for continuing this work. Since you've managed to make things backwards compatible, I've opened the former rule up such that now you can open PRs and merge them yourself or commit directly to the base branch.

I think we should refrain from moving to main for now since some users are using master as the target version. Perhaps a year down the line.

Also sorry for not keeping up to date with the conversation. I really appreciate you continuing this work!

[jcbhmr]

I think we should refrain from moving to main for now since some users are using master as the target version. Perhaps a year down the line.

No worries! ❤️ I wouldn't worry too much about Andrew-Chen-Wang/github-wiki-action@master though; there doesn't appear to be any public usage of it (github search) (sourcegraph search). (I don't know about private) #23

[jcbhmr]

@jcbhmr Thanks so much for continuing this work. Since you've managed to make things backwards compatible, I've opened the former rule up such that now you can open PRs and merge them yourself or commit directly to the base branch.

I want to caution that "backwards compatible" might not be the right word, and I want to make sure we're on the same page. I've tried to stick with the core idea of "push a folder to the .wiki.git repo", but I've done so by:

1. Changing from env: to with:
2. Adding more options
3. Changing the names of some of the options (WIKI_DIR => path:, REPO => repository:, etc)
4. Changing the core architecture of this project (Docker+Bash => Bash)
5. Using GIT_WORK_TREE and GIT_DIR instead of rsync

These changes, while good and (IMO) improvements, are nonetheless a new version and require changing a config. IDK if that's "backwards compatible" by the definition? 🤷‍♂️

      - uses: Andrew-Chen-Wang/github-wiki-action@v3
        # ⚠️ We use the env: key to provide our inputs! See #27.
        env:
          # Make sure this has a slash at the end! We use wiki/ by default.
          WIKI_DIR: my-octocat-wiki/
          # You MUST manually pass in the GitHub token.
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # These are currently REQUIRED options
          GH_MAIL: [email protected]
          GH_NAME: actions[bot]

to

      - uses: Andrew-Chen-Wang/github-wiki-action@v4
        with:
          path: my-octocat-wiki
          token: ${{ secrets.MY_TOKEN }}
        env:
          GIT_AUTHOR_NAME: Myself
          GIT_AUTHOR_EMAIL: [email protected]

hence, the v3 => v4 upgrade version bump. Which, again, is recommended practice! Bumping versions on improvements to the core idea of the project is good and that's what version tags are for, right? 😜

---

TLDR: I want explicit ✅ that going from (left) to (right) is 👍 for v4. Just to make sure we are on the same page.

I plan on merging all the PRs and then @-pinging you about making a v4.0.0 release. Sound good?
#40 #41 #42 #43 #44 #45 #47

[Andrew-Chen-Wang]

Yes this sounds good. Major version update sounds good. Can't remember if the PR for the README includes a header saying "Breaking Changes in v4" which can help people migrate. I noticed a migration section iirc so that's great.

Plan sounds good to me. Thanks again.

[jcbhmr]

@Andrew-Chen-Wang All done! It works!

[jcbhmr]

@Andrew-Chen-Wang Created release! https://github.com/Andrew-Chen-Wang/github-wiki-action/releases/tag/v4.0.0
🎉🎉🎉🎉

The v4 tag was created by GitHub Actions too!

[Andrew-Chen-Wang]

awesome thanks again!