Add github-server-url option (and more)

[jcbhmr]

This PR would...

• Add a github-server-url input option
• Change the description of repository to reflect that it's just user/repo now
• Change the descriptions in the readme to match
• Pass it in action.yml to the script
• Use it in the bash script
• Fix the test.yml token param that was still x:$TOKEN to just the default

This PR would also do

• Use gh CLI instead of plain git
• Use more GITHUB_* env vars to override/replace those from https://docs.github.com/en/actions/learn-github-actions/variables#default-environment-variables with the ones that the user wants (i.e. replace $GITHUB_TOKEN with $INPUT_TOKEN)
• ❓ Use GIT_* env vars to override/setup git features as defined https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables
• Remove git_exists.sh since we use catching-style instead of pretesting-style code for error handling
• Move src/index.sh to index.sh since having a folder for one file seems redundant. if we add more files in the future, re-add the src/ folder.
• Fix up some of the error print messaging >&2 stderr stuff when repo clone fails
  these things were outside the scope of what i originally wanted to do, but just kinda happened as i made more changes...

using more $GITHUB_* env vars has the added benefit of interop-ing well with gh since gh sniffs $GITHUB_TOKEN for its auth token

closes #68
closes #67
closes #59 via using gh instead of rolling our own
closes #2 via using gh which handles that for us

[jcbhmr]

@spenserblack requesting review
this is a relatively big pr

[jcbhmr]

Btw do you know what the gh repo sync command does? Is it akin to git pull or git push or both? I'm confused
https://cli.github.com/manual/gh_repo_sync

[spenserblack]

Never actually used repo sync, since I just do pull/push. But it looks like it's similar to VS Code's sync. So it pulls if the repo is behind, and pushes if the repo is ahead. Personally I'd prefer to continue using pull/push, but I guess some would want a catch-all command before and after making changes 🤷

[jcbhmr]

is this a good cleanup operation, or is there a better way? bash doesn't really have try-finally

[spenserblack]

Perhaps we can just naively cleanup at the end without any "try-finally" behavior. The majority of workflows would stop if this action fails, which basically "cleans up," except possibly in a self-hosted runner. On failure, the .git folder can continue to exist for the user's debug purposes.

[jcbhmr]

i added a bunch of logs with using the 🟥🟧🟨🟩🟦🟪⬛ emojis like log levels. i know gh actions have like fancy builtin ::warning:: or something.. should I be using that? 😆

https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions

[spenserblack]

🤔 Yeah, probably best to use the built-in log levels

[jcbhmr]

is it ok if i do that in a separate pr to avoid this getting too big, or do you want me to do it now?

[spenserblack]

🤔 Yeah, probably best to use the built-in log levels

[spenserblack]

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 ./.

[jcbhmr]

ohh shoot yeah
thats a problem when just plain git init-ing or git clone --bare-ing 😱

[jcbhmr]

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

?? 🤔

[spenserblack]

Perhaps we can just naively cleanup at the end without any "try-finally" behavior. The majority of workflows would stop if this action fails, which basically "cleans up," except possibly in a self-hosted runner. On failure, the .git folder can continue to exist for the user's debug purposes.

[jcbhmr]

closing in favor of more focused for things from #73