Skip to content
This repository has been archived by the owner on Dec 10, 2021. It is now read-only.

docs(ci-services): initial pass at detailed docs #648

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
102 changes: 102 additions & 0 deletions docs/ci-services.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
# CI Services

The CI services map defines the supported CI services the user will be
presented with when running the scaffolder.

## Example

```javascript
{
CIServiceName: {scaffolder: opts => scaffold(opts), public: true}
}
```

## Existing scaffolders
There are already multiple CI service scaffolders [available for
consumption](https://github.com/form8ion/awesome#continuous-integration-services).
Should your workflow fit into those, feel free to integrate them directly. If
not, you are welcome and encouraged to build more (and maybe consider
submitting a PR with a link 😎)!
trevtrich marked this conversation as resolved.
Show resolved Hide resolved

## Config

### keys: __string__

Keys in the CI services map define the choices the user will be presented with
when choosing their desired CI service. These have no functional impact on the
scaffolder.

example: `CIServiceName`

### values: __object__

Values in the CI services map define the actual mechanisms and configuration
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
that will be used by the JavaScript Scaffolder to scaffold the CI service for
the user's project.

#### scaffolder: __function__ (_required_)

Consumer-provided plugin called when this CI service is selected by the
user in the interactive prompt. Will be called with the following arguments:

* `projectRoot` __string__ full path to the directory where scaffolder will
create the JavaScript project
* `vcs` __object__
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
* `host` __string__ VCS hosting service to generate the repo with (e.g., `github`)
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
* `owner` __string__ account name on the host service for the repository to
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
generate (e.g., `form8ion`)
* `name` __string__ repository name to generate (e.g., `javascript-scaffolder`)
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
* `visibility` __string__ visibility of the project to be scaffolded (valid
values are: `Public`, `Private`)
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
* `projectType` __string__ type of project to be scaffolded (valid values are:
`Application`, `Package`, `CLI`)
* `nodeVersionCategory` __string__ node category chosen for the project (valid
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* `nodeVersionCategory` __string__ node category chosen for the project (valid
* `nodeVersionCategory` __string__ category of node version chosen for the project (valid

values are: `Latest`, `LTS`)
* `tests` __object__
* `unit` __boolean__ whether the project will be unit-tested
* `integration` __boolean__ whether the project will be integration-tested

*Response*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i typically call this results. not sure response is a good fit since that makes me think request/response, which i dont think this really is


The response object is commonly used across the project as a way for scaffolders
to communicate information to the parent.

* `nextSteps` __array__ list of strings that will be aggregated and displayed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* `nextSteps` __array__ list of strings that will be aggregated and displayed
* `nextSteps` __array__ list of objects with shape of {summary: __string__, description: __markdown string__} that will be aggregated and displayed

not quite a suggestion of exact content, but this is the more correct type

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i got this shape from here. am i understanding that one wrong?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, which might be pointing out confusing api design. the important piece to consider here is order of operations and apparently that multiple returned objects are using the same attribute name.

the results from sub-scaffolders, like the ci plugins, have this shape, which are processed in that case to create github issues for each one. the version that you linked to is a list of urls that point to the created issues. keep in mind that the subscaffolders dont know which processors will read the results and that the github one is only one processor

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, good to know 👍 . i went ahead and made the change, but i'm still confused. the docs we're shooting for in this change are the return values from the ci scaffolder. from what i'm seeing in the example you linked above it looks like the return value from the github scaffolder contains an object with nextSteps that is just a list of urls.

this is making me think you might be talking about the values passed in to the ci scaffolder, which i don't even have in the list of arguments to the top-level scaffolder on the ci-services object.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, right... yeah, we probably need to improve the naming even more if i'm getting confused by this. you're right that i was getting the input/output wrong, but the reason for me getting it wrong is that i was pointing out the version of nextSteps that is more consistently returned from general plugins. i was still thinking from the perspective of working toward documenting the general case and calling out how the specific cases differ from that. even calling out this difference is really confusing when they use the same name for very different purposes

to the user when all scaffolding is complete. This can be used to remind the
user about steps that the scaffolder is not able to complete or has not been
developed, but may be needed before considering scaffolding complete. (e.g.,
`['decide whether default dependency automation settings are appropriate']`)
* `devDependencies` __array__ list of strings containing dev dependencies to
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
be added to the project's `package.json` upon creation (e.g.
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
`@travi/travis-lint`)
* `scripts` __object__ a map of scripts to add to the project's
`package.json`
* `keys` __string__ the name of the script you would like added to the
`package.json` (e.g., `'disabled:lint:travis'`)
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
* `values` __string__ the script to run when called (e.g., `'travis-lint
.travis.yml'`)
* `badges` __object__
* `status` __object__ badges to be added to the `status` section of the
generated top-level README
* `keys` __string__ name used to identify this badge type (e.g.,
`github-actions-ci`)
* `values` __object__
* `text` __string__ (_required_) text you would like displayed on this
badge (e.g., `Build Status`)
* `img` __string__ (_required_) a url to the image for this badge. Each
CI service has it's own way of handling badging. See [adding a github
workflow status
badge](https://docs.github.com/en/free-pro-team@latest/actions/managing-workflow-runs/adding-a-workflow-status-badge)
for an example.
* `link` __string__ (_required_) a url to the build status you would like
trevtrich marked this conversation as resolved.
Show resolved Hide resolved
to navigate the user to when the badge is clicked.

#### public: boolean (optional)

Value will be used to determine whether to display this as an option pending
the user's selection of `visibility` in prior prompts.

#### private: boolean (optional)

Value will be used to determine whether to display this as an option pending
the user's selection of `visibility` in prior prompts.