it doesn't make sense to store ALLOWED_USERS in vault because:

• we anyway output the list of users who should approve it
• we don't have visibility and open control for allowed users within org, if some user leaves company or becomes team lead

In order to simplify managing of allowed users - lets move it under the github team control

• create a team in GH (something like tip bot approvers or similar)
• add existing allowed users (as long as they are in ParityTech org) - shawntabrizi, gavofyork, rphmeier, athei, andresilva, arkpar, bkchr, eskimor, drahnr, dvdplm, robbepop, cmichi, tomaka, pepyakin, kianenigma, rossbulat
• implement dynamic check of allowed user using github api

• [x] #16
• [x] Build the container on CI
• [x] Add Helm charts
• [x] Add job to deploy Helm charts on CI
• [x] Create new apps for prod & staging
• [x] Find out network for staging
• [x] Create new wallets (for prod & stage)

Depends on:

• https://github.com/paritytech/ci_cd/issues/485
• https://github.com/paritytech/ci_cd/issues/486

• [ ] Use yarn --immutable for installing dependencies (--frozen-lockfile is deprecated) https://github.com/paritytech/substrate-tip-bot/blob/5d55e2cd415ea2866e18e9a505cad0ca3100c2fe/Dockerfile#L13

Alongside the feature, following changes were made:

• Using opstooling-integrations for GitHub interations
• Upgraded probot, in order to align underlying octokit versions between opstooling-integrations and probot itself
• Upgraded opstooling-js for the same reason

• ES6 support in Dockerfile
• Migrated from jest to mocha as it's more ES6 friendly, similar API as Jest and far more performent
• Dropping yarn support - These days npm has reclaimed the Node package manager title back from Yarn, we can achieve better and more consistent results with npm, for example, version tagging, package upgrades, lock file installs

If these PRs are getting annoying @shawntabrizi, let me know (or if I can just merge them), I have a few more coming before I work on features

Ran into this one today:

INFO (server): POST http://localhost:3000/ - 200                               
ERROR (server):
    type: "error"
ERROR (server):
    type: "error"
    status: 520
    message: ""

Needed to restart the bot.

I haven't specifically run the linting over index.js as I intend to refactor this file and introduce ES6 JS features in following PRs.

Aiming to make these PRs as small as possible for visibility and ease of review

Also changed deploy to k8s job so it's no needed to restart the whole pipeline for re-deploying the app

cc https://github.com/paritytech/ci_cd/issues/544

@mordamax need your help here: what env variables should be added to helm? are there any secrets?

Close https://github.com/paritytech/ci_cd/issues/486

PR adds .gitlab-ci.yml, CODEOWNERS and adds labels to Dockerfile. Helm charts will be added in a different PR

Close https://github.com/paritytech/ci_cd/issues/485

No behavior in the tipping use-case is intended for this pull request, it only affects how the code is written and organized. Also note that conforming the module structure to https://github.com/paritytech/opstooling/pull/100 is out of scope for this pull request.

This PR

• Applies https://github.com/paritytech/opstooling-js and https://github.com/paritytech/opstooling-js-style
• Adjusts the code so that it conforms to the linting rules
• Adds GHA for linting so that linting rules are respected going forward
• Remove tests because they're useless

TODO

• [x] Try it out and see if it's working

close #13

The bot currently is posting the full error context into a github comment. As an example see here: https://github.com/paritytech/substrate/pull/12723#issuecomment-1321700543

It should only post:

@bkchr ERROR: Error: Contributor did not properly post their account address.

Make sure the pull request description has: "{network} address: {address}".

There are a bunch of ideas that we can do to take the tip bot to the next level:

• Allow users to submit their associated address ahead of time, either through some local DB or maybe just easier to maintain a JSON file which people can submit PRs to.
• Automatically pick the size of the tip based on the "Size of issue" tag on the PR
• Introduce new tag "tip" which allows the tip bot to execute on that PR
• Allow anyone (mainly the contributor) to trigger a tip one time, given the appropriate tags, the bot will execute
• Maybe a new tag "tip-paid" used to signal that the tip was paid.

This will improve the process for getting tips for good PRs. We can passively add this tag, and the users can themselves trigger the tip bot, rather than waiting for us to do it.

The only issue might be that we may not want to allow ANYONE to add a tip tag to the PR. Is it possible to limit certain kinds of tags?

This will only be really useful after we've deployed it to our infrastructure (#18).

Enable a /metrics endpoint. We can base ourselves in some metrics from https://github.com/paritytech/substrate-matrix-faucet/blob/82728e9e91e1978dbd623c616fe8e8c53dd8c7a7/src/server/routes/metrics.ts such as

• Balance of the tipper account
• RPC timeout, disconnection, error counts
• Number of requests sent

Either use a GitLab job for this (as demonstrated in https://github.com/paritytech/pr-custom-review/blob/4066ef64c8633fbc9a1b08a4d9442a784253f49a/.gitlab-ci.yml#L66 and https://github.com/paritytech/pr-custom-review/blob/4066ef64c8633fbc9a1b08a4d9442a784253f49a/.gitlab-ci.yml#L154) or a GitHub action (https://github.com/paritytech/opstooling-js-style/blob/a5b700ed4586dfead0ce3b5f7ff5d74f15b66cde/.github/workflows/pre-commit.yml#L49).

From @shawntabrizi on Matrix

2022-02-21 14:27:26          API-WS: disconnected from wss://[kusama-rpc.polkadot.io/](http://kusama-rpc.polkadot.io/): 1006:: Connection dropped by remot$
 peer.                                                                                                                   
2022-02-21 14:39:14          API-WS: disconnected from wss://[rpc.polkadot.io/](http://rpc.polkadot.io/): 1006:: Connection dropped by remote peer. 
2022-02-21 14:39:14        RPC-CORE: health(): Health:: disconnected from wss://[rpc.polkadot.io/](http://rpc.polkadot.io/): 1006:: Connection dropp
ed by remote peer.
2022-02-21 14:44:48          API-WS: disconnected from wss://[kusama-rpc.polkadot.io/](http://kusama-rpc.polkadot.io/): 1006:: Connection dropped by remote
 peer.
2022-02-22 14:20:20          API-WS: disconnected from wss://[rpc.polkadot.io/](http://rpc.polkadot.io/): 1006:: Connection dropped by remote peer.
2022-02-22 14:38:16          API-WS: disconnected from wss://[kusama-rpc.polkadot.io/](http://kusama-rpc.polkadot.io/): 1006:: Connection dropped by remote
 peer.
2022-02-22 14:38:16        RPC-CORE: health(): Health:: disconnected from wss://[kusama-rpc.polkadot.io/](http://kusama-rpc.polkadot.io/): 1006:: Connectio
n dropped by remote peer.
2022-02-22 14:59:58          API-WS: disconnected from wss://[rpc.polkadot.io/](http://rpc.polkadot.io/): 1006:: Connection dropped by remote peer.
2022-02-22 14:59:58        RPC-CORE: health(): Health:: disconnected from wss://[rpc.polkadot.io/](http://rpc.polkadot.io/): 1006:: Connection dropp
ed by remote peer.
2022-02-22 15:29:49          API-WS: disconnected from wss://[kusama-rpc.polkadot.io/](http://kusama-rpc.polkadot.io/): 1006:: Connection dropped by remote
 peer.
2022-02-22 16:20:33          API-WS: disconnected from wss://[rpc.polkadot.io/](http://rpc.polkadot.io/): 1006:: Connection dropped by remote peer.