Use Cases [WIP]

[Harjot1Singh]

What do we want, and for when? Let's list out what cases we have at each stage for all of our current repositories, and then generalise them:

Danger rules/semantic analysis

See #1. We can have this be reported at the end of testing. Unsure if danger should report any of the steps, or just own rules. Also, whether Danger rules are going to vary across type of repository, or not. Perhaps we just need a core set of rules, and the ability to extend by adding rules in-repo to cover specific use-cases. Maybe could run an npm run danger command or pick up a repo Dangerfile + merge it automatically.

Lint

Straightforward, npm run lint. Should use the eslint in the repository, depending on how the shared ESLint package forms.

Test

• npm run test, with coverage
• Coveralls support, generally?

Bump (only in master/dev)

• Bump as per semver rules
• If in dev, append WIP

Build

Questions

• Should this be down to each repository to manage their own build process?
  • I suspect so
• How do we handle build artifacts?

Use cases

• Gurmukhi-utils - npm universal library: Webpack or rollup.
• Presenter - Electron app: CRA build frontend + nothing for backend. But would like to build backend too. Looks like a case of a custom process, unless we could compose two actions together.
• Viewer - CRA: npm run build
• DB - custom: npm run build

The key appears to be that npm run build must be supported. For straight JS/npm libraries, we could export our own shared action, but it seems that this could vary if we are including devdependencies required to build the aforementioned libs in their repos.

Requirements

• Run npm run build
  • Support cross-platform builds
• Supply a shared action for building JS/TS libraries?

Publish (only in master/dev)

Questions

• How much of this should be left to the repository?

  • Personally, I suspect none. Main concern is electron-builder, which does all of it, but maybe it'd be better to turn publishing off and stick to building, to allow for standardisation, cross-repo.

• Publishing npm packages (gurmukhi-utils)

• Publishing to GH-releases - everything should have something that goes there, even if it's the default repository source with a changelog

  • Changelog
  • Optional artifacts

[bhajneet]

Another idea for danger, or some other kind of bot/automation. Would be to mention to the user if they haven't added a reviewer/assignee/labels to their PR if it's out of draft. Or to remind them to title the PR correctly to match commit guidelines header line (since we squash PRs).

[bhajneet]

If it's a first time contribution/PR, we can also congratulate or thank them (though I suppose we should do that every time a PR passes all CI/tests/linting and is merged in to dev)

[saihaj]

Or to remind them to title the PR correctly to match commit guidelines header line (since we squash PRs).

check this out https://github.com/shabados/docs/pull/50