Git Product home page Git Product logo

actions-wiki's Introduction

Publish to GitHub wiki action

CI Dogfood Test Check dist/ codecov

๐Ÿ“– Deploy docs from your source tree to the GitHub wiki

๐ŸŒ Works across repositories (with a PAT)
๐Ÿ“š Pretty interface for Markdown docs
โคด๏ธ Lets you open PRs for wiki docs
๐Ÿ’ป Supports runs-on: windows-*

Usage

GitHub Actions GitHub wiki

Getting started is easy! Just create a GitHub Actions workflow file that uses spenserblack/actions-wiki and you're good to go! ๐Ÿš€ Here's a ready-made example to help you blast off:

name: Publish wiki
on:
  push:
    branches: [main]
    paths: [wiki/**, .github/workflows/publish-wiki.yml]
concurrency:
  group: wiki
  cancel-in-progress: true
permissions:
  contents: write
jobs:
  wiki:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: spenserblack/actions-wiki@<version>
        with:
          # Whatever directory you choose will be mirrored to the GitHub
          # .wiki.git. The default is .github/wiki.
          path: wiki

Screenshot of 'Create the first page' button

โ— Make sure you turn on the GitHub wiki feature in your repo's settings menu. You'll also need to manually create a dummy page to initialize the git repo that powers the GitHub wiki. If you don't, when we push to your-repo.wiki.git, your workflow will fail because the wiki doesn't exist.

โš ๏ธ You'll need to remember to enable the contents: write permission! GitHub recently changed the default permissions granted to jobs for new repositories.

Publishing to a different repository

If you're pushing to a wiki that's not the current repository you'll need to get a GitHub PAT to push to it. The default ${{ secrets.GITHUB_TOKEN }} won't cut it! You can generate a PAT in your GitHub Settings.

For example, if you created octocat/gigantic-mega-project-wiki to hold the wiki and you want to publish it to the GitHub wiki that belongs to another repository like octocat/gigantic-mega-project, you'd use a step like this in one of your GitHub Actions workflows.

- uses: spenserblack/actions-wiki@<version>
  with:
    path: .
    # Notice that we use a github.com/ prefix here to support enterprise GitHub
    # deployments on other domains.
    repository: github.com/octocat/gigantic-mega-project
    # Make sure this token has the appropriate push permissions!
    token: ${{ secrets.GIGANTIC_MEGA_PROJECT_GITHUB_TOKEN }}

Options

  • repository: The repository housing the wiki. Use this if you're publishing to a wiki that's not the current repository. You can include a domain prefix if you have a hosted GitHub instance that you want to push to. Default is ${{ github.repository }} with the implicit github.com domain.

  • token: ${{ github.token }} is the default. This token is used when cloning and pushing wiki changes.

  • path: The directory to use for your wiki contents. Default: .github/wiki.

  • commit-message: The message to use when committing new content. Default is Update wiki ${{ github.sha }}. You probably don't need to change this, since this only applies if you look really closely in your wiki.

  • dry-run: Whether or not to actually attempt to push changes back to the wiki itself. If this is set to true, we instead print the remote URL and do not push to the remote wiki. The default is false. This is useful for testing.

Alternatives

There are quite a few GitHub wiki publishing actions on the GitHub Actions marketplace. There are, however, two that stick out. The newrelic/wiki-sync-action is a good choice for if you need bidirectional synchronization when someone edits the live wiki. This can be beneficial for less-technical contributors. There's also Andrew-Chen-Wang/github-wiki-action which is a direct competitor to this project. It offers more automatic features, but has more complex configuration. It also doesn't support runs-on: windows-*.

๐Ÿ“š If you're interested in more discussion of alternatives, check out #4.

Development

YAML Bash

This is a GitHub Action, so we inevitably use YAML. Make sure you quote the right things! To test ๐Ÿงช the action, the current workflow is to open a PR and then have the test.yml workflow run a dry-run: true iteration to (hopefully) spot any flaws.

To get a better handle on the contribution process, check out our handy contributing guide. Happy coding! ๐Ÿ‘‹

actions-wiki's People

Contributors

allcontributors[bot] avatar jcbhmr avatar spenserblack avatar yo-ga avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

actions-wiki's Issues

Consider reducing config clutter?

Having dist in source control is ok (if a little distasteful, but I digress) but there's a lot of clutter here! ๐Ÿคฎ I think we should reduce the clutter! ๐Ÿ˜
image

Some ideas:

Of those, I think these are the most feasible (easy)

  • prettierrc โžก package.json
  • CREDITS.md โžก README.md <details>
  • jest โžก vitest/node:test

Consider using git subtree

remote="$GITHUB_SERVER_URL/$GITHUB_REPOSITORY.wiki.git" # Or similar string concatenation
ref=$(git subtree split -P "$INPUT_PATH")
git push -f "$remote" "$ref:master"

This would...

  1. Keep a mirrored history of all the commits with proper authors and proper history for free since you are just "splitting out" a specific subfolder of git
  2. Make it so you have to commit things to the repo if they are generated by bots in the action itself (like a generated CHANGELOG.md that isn't committed, but want to post it to the wiki)
  3. Avoid the need to take inputs about the author and commit message and everything

Note that 2 is likely a downside, but could be mitigated; you can either force the user to use a commit action or git add CHANGELOG.md && git commit -am "Create changelog" themselves, or automagically run git commit in the action itself.

This probably would warrant a version bump. Currently, you're at v0.

image

I'd love to contribute code to do this. โค

/ref Andrew-Chen-Wang/github-wiki-action#18

Improve readme

๐Ÿ’กIDEA: Make the readme more visually interesting. I (@jcbhmr) have my own "style" that I've developed that could be used here, or if there's another way you'd prefer things to be laid out, I'm OK following your lead.

Here's some demos of what some of my readmes kinda look like: fake demo readme #1 fake demo readme #2 and a real world example and there's probably others you can find in my profile too.

Other ideas to improve general "advertising" are:

/assign jcbhmr

Split inline bash code into own script(s)

Discussed in #19

Even with other alternative ideas, it seems like a safe first step is to copy+paste the code into its own .sh file. In the future, maybe use a JS action or a Docker thing or some other technique. Who knows ๐Ÿคท

Add a header image to readme

Discussed in #29

Originally posted by jcbhmr March 17, 2023
Something like this? Might want to make the filenames actually line up, but the quick "what does this action do" is nice. even if there's already a title, an image like this clearly gets across what this action does and would be a good addition IMO

image

it's sort of like a blog post; they are better when they have an image, even if the image is only tangentially related to what the content is. I mean, just look at this: https://web.dev/blog/

image

wtf are these images?! they have almost nothing to do with html or js, and yet it's still better than just a plain text post. it helps break it up, and adds some "oh yeah that one" sort of like a profile picture for the project. it's like a "meme" in the truest technical sense of the definition.

Fix test script

image

from #57 where i wanted to see it go green

doesn't work for forks

likely problem: idk
likely solution: some fiddling with the github token perms in the settings tab?

basically the token needs READONLY perms to just the "contents: read" flag across forks which could be what's happening?

Consider using an auto-tag release bot

image

Currently tags seem to be aiming for a Docker-image like (that's the best analogy I can think of) tag system where for each version, there's like a major tag, a minor tag, and a patch tag.

So like v1.5.10 has:

  • v1.5.10
  • v1.5 => v1.5.10
  • v1 => v1.5.10

And then when v1.5.11 comes out, it updates:

  • v1 => v1.5.11
  • v1.5 => v1.5.11
  • v1.5.10 (stays pointing to pinned version)

And similarly, when v1.6.0 comes out:

  • v1 => v1.6.0
  • v1.5 => v1.5.11
  • v1.6 => v1.6.0
  • v1.6.0
  • v1.5.11
  • v1.5.10

At least I think that's what you're going for? It looks like the official GitHub actions use this technique: https://github.com/actions/checkout/tags

Here's a GitHub workflow action that might help automate this: https://github.com/actions/publish-action I know I know it's still in beta, but it is actively being used by GitHub's official actions (and others)! https://github.com/actions/publish-action/network/dependents And you can pin it to a specific commit if you don't want to get skewered by version bumps.

[Milestone] v1

If I had the power to make this a Milestone in GitHub, I would ๐Ÿ˜‰
this is the list of things that I think are @spenserblack has already agreed upon as "things to do for the v1 release"
inspired by #44

  • use path instead of wiki-directory #52
  • have repository input support bare user/repo slugs without github.com prefix #67
  • have a dry-run input to not do push #51
  • mirror token: ${{ secrets.GITHUB_TOKEN }} default token input format from other actions #59

Create v0.3.0

v0.2.0...main

the big change is that tokens have been fixed to work without x:${{ github.token }} in every single workflow file being required

- if ! git_exists "https://$INPUT_TOKEN@$INPUT_REPOSITORY.wiki.git" &>/dev/null; then
+ if ! git_exists "https://$GITHUB_ACTOR:$INPUT_TOKEN@$INPUT_REPOSITORY.wiki.git" &>/dev/null; then

- git remote add origin "https://$INPUT_TOKEN@$INPUT_REPOSITORY.wiki.git"
+ git remote add origin "https://$GITHUB_ACTOR:$INPUT_TOKEN@$INPUT_REPOSITORY.wiki.git"

Force-push new history with a single commit for the default deployment strategy

The purpose of this repo was to make the main repository the source of version control for the wiki, instead of a separate repository (with very different security and UI). Given that the history is preserved in the main repository, it might be worth considering a simpler, more destructive strategy for deploying the wiki.

This could resolve #72


This is somewhat inspired by instructions for manually deploying to gh-pages in the Vue CLI docs, which is

set -e

npm run build
# or
yarn build

cd dist

git init
git add -A
git commit -m 'deploy'

# deploy to gh-pages
git push -f [email protected]:OWNER/REPO.git master:gh-pages

cd -

It might also be worth taking inspiration from peaceiris/actions-gh-pages.


If a strategy option is added, this would be called the orphan strategy.

Add README.txt or something for locally cloned wikis

Discussed in #46

Originally posted by jcbhmr March 22, 2023
I just had the random thought to include some kind of a file that would not be visible on github but would be if you cloned the wiki locally to say "heyyyy checkout the github repo instead, don't put stuff in the wiki here!"

similar idea i had just now while writing this would be to prepend a <!-- DO NOT EDIT ON PUBLISHED WIKI, ONLY EDIT IN SOURCE REPO -->\n or similar comment to all .md files to discourage editing the published version?

these ideas are kinda redundant if the user sees the "github-actions[bot] edited this" thing though... ๐Ÿคทโ€โ™€๏ธ
image

Add a devcontainer config file

A bit off-topic for this PR, but would you be willing to make a PR to set up .devcontainer/devcontainer.json? If we, and other contributors, have a common setup for our editors, it might be easier to agree on certain styles and dev experiences. I'd be happy to offer advice if you have questions about setting up codespaces.

Originally posted by @spenserblack in #13 (comment)

Consider renaming to "spenserblack/publish-wiki-action"

I think this is a relatively cosmetic-level change. There's 301 redirects, so nothing would change for folks still using spenserblack/actions-wiki

This is largely motivated by branding, and SEO and all those good advertising things. And just good naming conventions in general. To quote myself

A lot of the names are honestly kind of vague. something like "actions/publish-wiki" is short and punchy, but since we aren't in the https://github.com/actions org, the next best thing is name/actions-publish-wiki maybe? Or publish-wiki-action? I'm basing this naming convention on the existing actions/* projects like "actions/deploy-pages" and "actions/configure-pages" and "actions/checkout". See https://github.com/jcbhmr/publish-wiki-action/issues/12 for more.

My personal favorite name would probably be "name/publish-wiki-action".

โ€” https://github.com/jcbhmr/publish-wiki-action/issues/8#issuecomment-1461120686

publish-wiki-action

or if possible

some-actions-org/publish-wiki

https://github.com/jcbhmr/publish-wiki-action-OLD/issues/12

This is an opinionated suggestion that you can close and I'll accept that. This is just a suggestion of my own thoughts on the naming stuff.

path=. confusion

Just realized that this could have a potential conflict with the documented usage to use path: ., since a .git directory will likely already exist at ./.

Originally posted by @spenserblack in #70 (comment)

we could use:

  • GIT_DIR is the location of the .git folder. If this isnโ€™t specified, Git walks up the directory tree until it gets to ~ or /, looking for a .git directory at every step.
  • GIT_WORK_TREE is the location of the root of the working directory for a non-bare repository. If --git-dir or GIT_DIR is specified but none of --work-tree, GIT_WORK_TREE or core.worktree is specified, the current working directory is regarded as the top level of your working tree.
    from https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables

and basically do

export GIT_DIR=../wiki.git
export GIT_WORK_TREE="$INPUT_PATH"
gh repo clone "$GITHUB_REPOSITORY" "$GIT_DIR" -- --bare
git config --unset core.bare
git reset

?? ๐Ÿค”

Do you actually need a user-generated GitHub PAT?

I notice from the readme:

Unfortunately, ${{ github.token }} does not have access to updating wiki repositories, so it is necessary to create a new PAT.

I don't think this is true? I was under the impression from my own attempt at a sub-par wiki action https://github.com/jcbhmr/publish-to-github-wiki that you can just use the ${{ github.token }} as long as you have the content: write permission.

name: Test publish to own wiki
on:
  push:
    paths:
      - index.sh
      - action.yml
      - .github/workflows/test-publish-to-own-wiki.yml
      - wiki/**
concurrency: test-publish-to-own-wiki
jobs:
  test-publish-to-own-wiki:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      # This just uses the secrets.GITHUB_TOKEN (or github.token, both are equivalent)
      - uses: ./

Recently GitHub did change up their permissions defaults to make them no longer write-permissive by default which may have thrown things off? I have already been bitten by this: devcontainers-community/features#2

Am I completely wrong? Is there something I'm missing? ๐Ÿคทโ€โ™‚๏ธ

Would you be interested in consolidating with Andrew-Chen-Wang/github-wiki-action ?

If we were to fix the following problems with https://github.com/Andrew-Chen-Wang/github-wiki-action that this repo https://github.com/spenserblack/actions-wiki has advantaged over it, would you @spenserblack be interested in consolidating the ecosystem?

Here's a list of things that https://github.com/Andrew-Chen-Wang/github-wiki-action CANT DO NOW but this repo can (you could advertise these on the readme!):

Would you be interested in collaborating with me to combine/interfold/whatever this repo, the git subtree trick from https://github.com/jcbhmr/publish-wiki-action-OLD and mash those changes into the https://github.com/Andrew-Chen-Wang/github-wiki-action ?

Andrew-Chen-Wang/github-wiki-action#19

If not, that's OK too. It's good to have competition in an ecosystem! โค

Support ignoring files in the wiki folder

Random idea I had in #46 (comment)

Possibly implementations:

  • Another with: input (ignorelist format?)
  • An actual ignorefile (wikiignore)

Workarounds:
A .gitignore in the wiki folder, combined with force-added files via git add -f path/to/wiki/file, should track the files in the repo, but ignore them when pushing to the repo. Untested.

Publish v0 tag

Right now there's the following tags:

image

I think a v0 tag would be a good idea. It can be auto-generated by a manual release! All we need to do is create a new release...

do this whenever a new fancy feature gets added, I guess? or do it manually.

Add github-server-url input

spenserblack are you ok with splitting into repository: and github-server-url: options? actions/checkout does this. https://github.com/actions/checkout#usage

image
image

Originally posted by @jcbhmr in #67 (comment)

Approved as OK to do!

are you ok with splitting into repository: and github-server-url: options?

Yes, that's preferable ๐Ÿ‘ Many inputs are missing from this action not because of a preference to omit them, but because they weren't required for a minimally viable release.

Consider splitting action.yml Bash script into its own file

If you're dead-set on maintaining Windows compatibility, I think this would require some testing to make sure that #!/bin/bash works to then ./my-script.sh on a Windows system. I think it does, but I would still test it to be sure.

But realistically, most people are going to use runs-on: ubuntu-latest for just this specific action.

# This is probably what most people are going to use this action for...
on: push
jobs:
  wiki:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: spenserblack/actions-wiki@vN
      # And that's literally it.

But hey, there might be a compelling reason that I'm missing!

Enable discussions on this repo

Some of these issues seem like they should be discussions.

opinion time I use discussions to discuss ideas and then issues to track todos. In the spirit of this, around the time where I get "maybe consider this idea"-type posts/ideas, I usually enable the discussion tab. GitHub also has great integration for this workflow with a "Create Issue from Discussion" button!

p.s. also consider disabling the Projects tab if you're not using it? That's my ocd speaking.

I know you have your own workflow; if you prefer to keep all these text posts in Issues tab instead, that's OK too. โค๏ธ

Support non-master default branch

For now, the script pull master branch and work on it. However, the GitHub has changed the default branch for new repositories from master to main. Kindly add the optional parameters for choosing the branch.

Add CONTRIBUTING.md

Just to make it more inviting and stuffs like that. Also maybe add a contributing note to the bottom of the readme

/assign @jcbhmr

How does this compare to newrelic/wiki-sync-action?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.