Toolkit: Create getting started template repo for script based action

[bryanmacfarlane]

Create a getting started repo with the right patterns of gitignore, husky usage, build, test and consuming toolkit from targz + install. (that will change after public availability so we should branch it appropriately)

[damccorm]

Could you create a repo for this and #17 in the actions org?

[chrispat]

These should be template repositories I would think https://github.blog/2019-06-06-generate-new-repositories-with-repository-templates/

[bryanmacfarlane]

@chrispat - I like that suggestion. Any preference on the repo name?

@vtbassmatt as fyi

[chrispat]

No preference on the repo name I will leave it to @vtbassmatt to figure out

[bryanmacfarlane]

I will pick some. Rename is an awesome feature ;)

[bryanmacfarlane]

https://github.com/actions/start-vm-action

[vtbassmatt]

I think we're calling them "javascript actions" so I'll rename that ;)

[damccorm]

Added a first draft template, I don't have admin privileges though so I can't mark it a template repo

[bryanmacfarlane]

@damccorm - done

[damccorm]

Made it a template action. Also renamed it to actions/javascript-template since I think that's closer to what we're looking for in terms of branding. @vtbassmatt if you have another name in mind feel free to update

[bryanmacfarlane]

Both the container action and the vm / host based can both run javascript (thus the toolkit for both written in javascript). The key difference is one runs on the host / vm and one runs the logic in a container.

I would suggest host-template and container-template.

I'll defer on renaming till @vtbassmatt confirms

[vtbassmatt]

The names I've been using - and trying to make official - are "container actions" and "JavaScript actions". I _think_ that distinction will resonate more with customers than host/VM, but rather than speculate, let me ask for a quick study from UX.

[bryanmacfarlane]

Note that we do have a handler concept so we can add the ability to write actions in other scripting languages. For example, we've considered powershell core but perhaps in the future python or bash is an option.

So expanding on your distinction, I would suggest container and script actions as the general marketing terms. However, since this specific template is for a javascript task then inline with that, it would be fine to use javascript-template. A final option would be a node-template since it's really just not javascript, it's specifically node that we run it with.

If we wanted to look a little bit ahead, we might want to call this the node12-template as we are about to change the runner to carry 12 (just LTS) and the files that would be in the template (node d.ts etc) and the handler would have to be node12, would be specific to node12. It would also drive home exactly what's going to happen.

Thoughts?

[vtbassmatt]

I actually like that. How about node12-vm-template since we're being that precise?

[vtbassmatt]

(or node12-host-template since not all non-container is VM... now I'm splitting hairs though...)

[bryanmacfarlane]

I think node12-template is fine.

[bryanmacfarlane]

Done. Changed it to node12-template

Ting is also moving the runner to node 12 this morning.

[damccorm]

Cool, thanks! For consistency, does actions/container-template make sense for the other template repo?

[bryanmacfarlane]

Yes. Just renamed it to container-template

@damccorm - after you get done with node12 template, start on that one. We should decide what base image we want to encourage in that template. I think a node alpine container from docker hub is good for a compute or SDLC type container action.

[damccorm]

Going to close here since the template is done. We can follow up with any proposed changes as issues in that repo.