Describe the bug

The usage of sed in this template fails in macOS, i.e. with:

• invalid command code v
• No such file or directory

(see details below)

Steps to reproduce

1. Generate a new repo based on this template.
2. Run bash setup.bash (on a Mac).

Expected behavior

1. [...]
2. sed not giving warnings as below.

Screenshots

After confirmation, the `main` will be replaced with the generated
template using the above information. Please ensure all seems correct.
Type `yes` if you want to continue.
> yes

Switched to branch 'template'
Preparing worktree (detached HEAD 81a8d50)
HEAD is now at 81a8d50 Initial commit
Switched to a new branch 'out'
sed: 1: "/Users/vs/src/mpv/asdf- ...": invalid command code v
sed: \033[35m.gitlab-ci.yml\033[m: No such file or directory
sed: \033[35mREADME-github.md\033[m: No such file or directory
sed: \033[35mREADME-gitlab.md\033[m: No such file or directory
sed: \033[35mcontributing-github.md\033[m: No such file or directory
sed: \033[35mcontributing-gitlab.md\033[m: No such file or directory
setup.bash: line 111: lib/utils.bash.sed: No such file or directory
sed: \033[35mREADME-github.md\033[m: No such file or directory
sed: \033[35mREADME-gitlab.md\033[m: No such file or directory
setup.bash: line 111: lib/utils.bash.sed: No such file or directory
setup.bash: line 111: .github/workflows/build.yml.sed: No such file or directory
sed: \033[35m.gitlab-ci.yml\033[m: No such file or directory
sed: \033[35mREADME-github.md\033[m: No such file or directory
sed: \033[35mREADME-gitlab.md\033[m: No such file or directory
sed: \033[35mcontributing-github.md\033[m: No such file or directory
sed: \033[35mcontributing-gitlab.md\033[m: No such file or directory
setup.bash: line 111: lib/utils.bash.sed: No such file or directory
sed: \033[35mREADME-github.md\033[m: No such file or directory
sed: \033[35mREADME-gitlab.md\033[m: No such file or directory
sed: \033[35mREADME-github.md\033[m: No such file or directory
sed: \033[35mcontributing-github.md\033[m: No such file or directory
sed: \033[35mREADME-gitlab.md\033[m: No such file or directory
rm '.gitlab-ci.yml'
rm '.gitlab/issue_templates/Bug_Report.md'
rm '.gitlab/issue_templates/Feature_Request.md'
rm '.gitlab/merge_request_templates/Merge_Request.md'
rm 'README-gitlab.md'
rm 'contributing-gitlab.md'
[out (root-commit) 5072db0] Generate asdf-octopilot plugin from template.
 26 files changed, 441 insertions(+)
 create mode 100644 "\033[35m.gitlab-ci.yml\033[m.sed"
 create mode 100644 "\033[35mREADME-github.md\033[m.sed"
 create mode 100644 "\033[35mREADME-gitlab.md\033[m.sed"
 create mode 100644 "\033[35mcontributing-github.md\033[m.sed"
 create mode 100644 "\033[35mcontributing-gitlab.md\033[m.sed"
 create mode 100644 .editorconfig
 create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md
 create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md
 create mode 100644 .github/PULL_REQUEST/pull_request_template.md
 create mode 100644 .github/dependabot.yml
 create mode 100644 .github/workflows/build.yml
 create mode 100644 .github/workflows/lint.yml
 create mode 100644 .github/workflows/release.yml
 create mode 100644 .github/workflows/semantic-pr.yml
 create mode 100644 .tool-versions
 create mode 100644 LICENSE
 create mode 100644 README.md
 create mode 100755 bin/download
 create mode 100755 bin/install
 create mode 100755 bin/latest-stable
 create mode 100755 bin/list-all
 create mode 100644 contributing.md
 create mode 100755 lib/utils.bash
 create mode 100755 scripts/format.bash
 create mode 100755 scripts/lint.bash
 create mode 100644 version.txt
Switched to branch 'main'
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.
  (use "git pull" if you want to integrate the remote branch with yours)
All done.
Your main branch has been reset to an initial commit.
Push to origin/main with `git push --force-with-lease`
Review these TODO items:
[...]

Additional context

https://github.com/asdf-vm/actions/releases/tag/v1.1.0

The generate link in README.md is missing. I'm guessing it refers to a script to generate the content for the plugin instance. In any event, I'd prefer to start an asdf-plugin from some (debugged, sanctioned) template rather than copying an existing one (however good it might be). In the meantime, I'll review a few to grok the pattern(s).

Great tool, I use asdf all the time and would like to asdfify a tool whenever it's missing. For projects that release on github, I would think that's a pretty easy and mechanical process. After climbing the learning curve, of course.

Describe the bug

The plugin template is violating the asdf project's "golden rules" for portability

Most specifically it's using echo and source liberally, and these have been considered "banned commands" for more than a year. (I understand these are bash scripts and can make assumptions but... still!)

Steps to reproduce

read the source, or generate the template

Expected behavior

No golden rule violations. In fact I'd expect the template to be enforcing this as part of linting?

Screenshots

Additional context

https://github.com/asdf-vm/asdf/blame/fce6c534daf6c0b2eed7dc633b18f7b87f665d2f/test/banned_commands.bats#L5-L24

Is your feature request related to a problem? Please describe.

If the distributor of a tool does not ship the tool bin with executable bit set or in other circumstances, the install will fail because of the missing permission bit. A plugin developer has to add a chmod +x on its own, instead of the template already taking this burden.

Describe the solution you'd like

Instead of creating chore work, maybe not fail when exec perm check fails, but try to set +x first. If the file itself is missing due to a failed install, it will still fail, which seems fine.

Describe alternatives you've considered

Let every plugin dev stumble over package maintainers not setting an exec bit and re-iterate with adding a chmod.

Describe the bug

Failed test in GitHub actions since semver is specified in template's build.yaml file.

Describe the bug
After Using the template to create the plugin repository, I noticed that without adding a .tool-versions file, the build fails

I had to add below to .tool-versions for the actions to run properly

nodejs 16.1.0
shfmt 3.2.4

Steps to reproduce

pick any tool, create the repository using the use template button and then push.

Expected behavior

If the Shellcheck and Shell Format are good then the action should pass

Screenshots

Additional context

Look at https://github.com/comdotlinux/asdf-lazydocker/runs/2583308115?check_suite_focus=true for more details.
P.S. Ignore the commit message : I accidently used the same commit message as previous, this build has one entry in .tool-versions nodejs 16.1.0.

Also I had to create a ASDF_DOWNLOAD_PATH="/tmp/${TOOL_NAME}" variable in lib/utils.bash for the build to work.

Steps to reproduce

Run bash setup.bash with a tool homepage url like https://github.com/user/repo#readme

Expected behavior

setup.bash replaces <TOOL HOMEPAGE> with the url.

Describe the bug

The fix applied in #53 needs to be applied for setting up gitlab projects

Steps to reproduce

run bash setup.bash --gitlab, and answer the questions

it will fail with a message similar to fatal: Invalid prefix, prefix cannot start with '/'

after applying a similar fix, it resolved the issue

Expected behavior

for the setup to work :)

In its documentation, https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions, GitHub recommends to pin GitHub actions to a full length commit SHA.

The Disadvantage of this is that it's more work compared to pinning actions to a tag. But it can be simplified by letting Dependabot handle the dependency upgrades.

One nice side effect is that there will be more activity to the repository. So this helps preventing scheduled GitHub Actions from becoming disabled when there is no activity for X consecutive days. Note that this is less needed by plugins in adsf-community because it seems there is a bot that generates activity every now and then (see "Update .github/CODEOWNERS" commits in https://github.com/asdf-community/asdf-graalvm/commits/master for exemple).

Should GitHub action pinning to a full length commit SHA be applied to this template repository ?

Describe the bug

If git's user.email option is not set, plugin creation fails.

Steps to reproduce

1. Clone a repo without the git's global user.name option configured (you can temporarily rename ~/.gitconfig to achieve this effect)
2. Run bash setup.bash
3. Observe the error messages at the end (just before the TODO issues are shown).

Expected behavior

If the user.email option is not set, the script should ask for one.

Screenshots

william@t450s: ~/asdf-mytool-plugin$ git config -l
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
[email protected]:wpyoga/asdf-mytool-plugin.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.main.remote=origin
branch.main.merge=refs/heads/main
william@t450s: ~/asdf-mytool-plugin$ bash setup.bash 
Name for your plugin, starting with `asdf-`, eg. `asdf-foo`
> asdf-mytool-plugin

Shell command for testing correct tool installation. eg. `foo --version` or `foo --help`
[mytool-plugin --help] > 

Your GitHub username
> my-github-username

Your name
> My Real Name

The tool's GitHub homepage.
[https://github.com/my-github-username/mytool-plugin] > 

The tool's documentation homepage if necessary.
[https://github.com/my-github-username/mytool-plugin] > 

Please choose a LICENSE keyword.
See available license keywords at
https://help.github.com/en/github/creating-cloning-and-archiving-repositories/licensing-a-repository#searching-github-by-license-type
License keyword:
mit/[apache-2.0]/agpl-3.0/unlicense > 

Setting up plugin: asdf-mytool-plugin

author:        My Real Name
plugin repo:   https://github.com/my-github-username/asdf-mytool-plugin
license:       https://choosealicense.com/licenses/apache-2.0/


mytool-plugin github:   https://github.com/my-github-username/mytool-plugin
mytool-plugin docs:     https://github.com/my-github-username/mytool-plugin
mytool-plugin test:     `mytool-plugin --help`

After confirmation, the `main` will be replaced with the generated
template using the above information. Please ensure all seems correct.
Type `yes` if you want to continue.
> yes

Already on 'template'
Preparing worktree (detached HEAD e518561)
HEAD is now at e518561 Initial commit
Switched to a new branch 'out'
rm '.gitlab-ci.yml'
rm '.gitlab/issue_templates/Bug_Report.md'
rm '.gitlab/issue_templates/Feature_Request.md'
rm '.gitlab/merge_request_templates/Merge_Request.md'
rm 'README-gitlab.md'
rm 'contributing-gitlab.md'

*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'william@t450s.(none)')
error: refname refs/heads/out not found
fatal: Branch rename failed
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
All done.
Your main branch has been reset to an initial commit.
Push to origin/main with `git push --force-with-lease`
Review these TODO items:

Additional context

Is your feature request related to a problem? Please describe.

ASDF does not very precisely document it's relying on the tool binary being installed in $install_path/bin/toolname.

Describe the solution you'd like

It would be good to make this more clear in the TODOs inside lib/utils.sh for any plugin developer, as it takes a while to figure this out.

The install routine is also implicitely relying on this during the exec permission check, but in many if not most cases, extracting the tar ball will not place the tool into the $install_path/bin subfolder.

Describe alternatives you've considered

None?

Describe the bug

First of all thanks a lot for the great tool, I'm happily using it since years now 🙂

Using this template as a base I'm trying to develop a plugin for Kiota.
The current version is here: https://github.com/andreaTP/asdf-kiota

To get things working I have had to craft the script to sanitize the paths passed by the env variables, done here.
Unfortunately, this doesn't (probably) play nicely with the GH actions that are still failing.

Without the mangling, the variables are looking pretty strange, e.g.:

ASDF_DOWNLOAD_PATH=/Users/<user>/.asdf/downloads/kiota/https://github.com/microsoft/kiota/releases/tag/v1.1.3

Here I'm asking for guidance on how to proceed to fix the CI and possibly follow best practices in the plugin development.
Thanks in advance!

Is your feature request related to a problem? Please describe.

Recent versions of git will disallow git read-tree --prefix=/ ...
See: https://www.spinics.net/lists/git/msg433678.html
The template will fail if using a recent version of git.
Tested on git version 2.36.0

Already on 'template'
Preparing worktree (detached HEAD 843b4d4)
HEAD is now at 843b4d4 Initial commit
Switched to a new branch 'out'
fatal: Invalid prefix, prefix cannot start with '/'

Describe the solution you'd like

git read-tree --prefix="" ... seems to work for setup.bash changing the below line.
https://github.com/asdf-vm/asdf-plugin-template/blob/main/setup.bash#L170

I am not sure if this is the most robust solution.

Thanks for providing this template!

Describe the bug

"The tool's GitHub homepage." does not propose the repository as asdf- prefixed.

Steps to reproduce

1. run ./setup.bash after repository generation from template...
2. reply to question "Name for your plugin, starting with asdf-, eg. asdf-foo": e.g. asdf-plug
3. reply to question "Your GitHub username": e.g. paulo-ferraz-oliveira
4. the script proposes https://github.com/paulo-ferraz-oliveira/plug

Expected behavior

The script proposes https://github.com/paulo-ferraz-oliveira/asdf-plug.

Screenshots

Not applicable.

Additional context

Not applicable.

Describe the bug

The template badges are incorrect

Steps to reproduce

Expected behavior

Got:

![Build](https://github.com/jthegedus/asdf-test/workflows/Build/badge.svg)

Wanted:

[![Build](https://github.com/jthegedus/asdf-test/actions/workflows/build.yml/badge.svg)]#(https://github.com/jthegedus/asdf-test/actions/workflows/build.yml)

Screenshots

Additional context

Describe the bug

Failed test in GitHub Actions because an error, "curl option -fsSL -H 'Authorization: token ***' is unknown" occurred.

Change asdfa-vm -> asdf-vm

Is your feature request related to a problem? Please describe.

GitHub & GitLab default to main now instead of master. By moving this repo to main usage of this template will set the default of the new plugin to main. asdf-core now supports updating plugins with non-master branches now by detecting the default branch of the remote, so this won't cause issues there.

Describe the solution you'd like

Set this repo's default branch to main

Update internal usage of master to main

Describe alternatives you've considered

NA

Additional context

Describe the bug

It was fixed shellcheck release url in PR #9 but not changed in template's lint.yaml file.

Is your feature request related to a problem? Please describe.

Plugin authors should track changes of their plugin in a changelog

Describe the solution you'd like

Including a changelog with some automation (GitHub Actions somehow) may increase changelog usage amongst plugin authors

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Most plugins do not offer any form of security guarantee. Most authors probably haven't considered adding one. A default file in their repo would force authors to address this.

Describe the solution you'd like

Each plugin either

a. explicitly offers a security guarantee
b. explicitly does not offer a security guarantee

Adding a default to this template would make authors consider their position

Describe alternatives you've considered

Increase awareness of asdf consumers of their security responsibilities/due diligence.

Additional context

Describe the bug

When installing, lib/utils.bash uses test -x "$install_path/bin/$tool_cmd" to check if the installed binary is executable.

tool_cmd is made up from tool_cmd="$(echo "shellspec --version" | cut -d' ' -f2)". This makes the test fail, as the cut extracts the parameters, not the binary name:

asdf-shellspec: Expected /tmp/tmppath/.../shellspec/bin/--version to be executable.

Steps to reproduce

1. Create a new plugin from the template
2. Adapt the lib/utils.bash as needed
3. Try install, watch it fail

Expected behavior

Do not fail.

suggestion: use cut -d' ' -f1 instead (I did for shellspec)

Describe the bug

When using setup.bash, choosing an MIT license does not replace [year] and [full name] in the license text.

Steps to reproduce

1. Create a new repo from this template.
2. Use setup.bash and choose MIT as your license.
3. Take a look at the generated LICENSE file.

Expected behavior

-Copyright (c) [year] [fullname]
+Copyright (c) 2020 Oliver Bertuch