
* expire with existng cleanup service * expire with new temp user service * make Drone happy :) * add expiry status * remove other approach * cleanup * add test for idempotency * add migration from datetime to unix ts * update cmd names * change lifetime config to duration * remove unnecessart formatting * add comment * update docs * remove max bound and introduce min error * simplify sql * remove comment * allow any outstanding to exist for at least 24 hours * revert created ts change Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com> * add extra state check to cleanup step Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
Building the docs locally
When you contribute to documentation, it is a good practice to build the docs on your local machine to make sure your changes appear as you expect. This README explains the process for doing that.
Requirements
Docker >= 2.1.0.3
Build the doc site
- In the command line, make sure you are in the docs folder:
cd docs
. - Run
make docs
. This launches a preview of the docs website athttp://localhost:3002/docs/grafana/latest/
which will refresh automatically when changes to content in thesources
directory are made.
Content guidelines
Edit content in the sources
directory.
Using relref
for internal links
Use the Hugo shortcode relref any time you are linking to other internal docs pages.
Edit the side menu
Edit sources/menu.yaml to make changes to the sidebar. Stop and rerun the make docs
command for changes to take effect.
Add images
Images are currently hosted in the grafana/website repo.
Deploy changes to grafana.com
When a PR is merged to master with changes in the docs/sources
directory, those changes are automatically synched to the grafana/website repo and published to the staging site.
Generally, someone from marketing will publish to production each day, so as long as the sync is successful your docs edits will be published. Alternatively, you can refer to publishing to production if you'd like to do it yourself.