Add a help command for users to explore and configure upptime.

Convert incident files inside the incident folder names to random names like heyhappylama.md.

memoize .uclirc config to reduce file reads.

README.md says npm install -g upp which install another package named upp.

The correct one seems to be npm i @upptime/upp

Handle edge cases by testing it rigorously. Improve user experience.

config cmd to update and add settings to .uclirc.yml.

Get commits using

git log --pretty=format:"%h%x09%ad%x09%s" --date=default  --all --first-parent --remotes --reflog --author-date-order -- __filename__

calculate response times and generate readme

update status command

Commit:: 7011a2c

Issue

Verifying SSL Peer certificate raises error for most of the websites.

Steps to Reproduce

Uncomment line 17 of src/helpers/request.ts

Possible Solution

1. https://github.com/JCMais/node-libcurl/blob/develop/COMMON_ISSUES.md

https://pm2.io/docs/runtime/reference/pm2-programmatic/
https://pm2.keymetrics.io/docs/usage/pm2-api/

Release NPM beta release,

• automate releases using GitHub Actions
• understand the working of semantic-release bot
• find solution to auto-update user's CLI tool without using S3 buckets.

Use the incidents properties to calculate downtime.
Add logic to /src/helpers/calculate-uptime.ts

Adding more fields in rc file such as
schedule time:
issues:
providers:
commits:
pages:
etc

TODOs

• check whether .uclirc.yml already exists
• check whether repository is git initialised
• add all generated log files to .gitignore

Design a graphs api.

Make a new repo which uses chart.js to build interactive graphs. Make the package accept both .uclirc.yml and .upptimerc.yml.

Add init command to initialize a new uclirc.yaml file with user configurations.

TL;DR

Use provider specific workflows/actions to sync issue created as files. Write workflows/actions specific to the platform and use the platform agonist tool.

Benefits

1. No dependency on a specific api
2. Integrations with any platform will be a breeze.

Implementation

Issues created as files by the tool will be pushed to the remote repo(if specified), actions will trigger on changes made to issues/*/*.md and will generate issues on remote.

issues/slugified-name/an-issue.md will have yaml front matter which will contain meta fields. Comments will be separated using md-comments, example <!--start:comment:1--> COMMENT <!--end:comment:2-->.

Since, the template will require seldom PRs. We can sync issue-numbers by defining actions which will be triggered on any newly created PR, and will increase the offset in the root level incidents.yml.

Possible Pit-falls

Syncing issue-numbers would be difficult with some providers. GitHub, for example, has discussions in which discussion gets a id. We may define actions for every created discussion, but discussion-actions are not available yet (though, it is on their road-map).

Questions

1. Should we really sync issue-numbers?
2. Keeping in mind, the benefits and possible pit-falls, is it a good way to do things?

Add notifications func

Add upp run command.

TODOs:

• Add spinners
• Devise a mechanism to clear console at periodic intervals, or after say, 20 lines
• Quiet mode

This command will list all the incidents on the monitoring websites(default behavior)

• reading the incidents file
• display results in table
• active flag
• past incidents flag

Refactor config command,

• make spawn editor code platform aware
• ask user what to config using inquirer
• add config options for .env

Instead of relying on a separate graphs package, I propose including the functionality in here.

Benefits

1. upptime/cli has helper functions required by Graphs func.
2. Reduce overhead ❓
3. dir /api is no longer needed to generate badges.

• active flag
• past incidents flag