Giter VIP home page Giter VIP logo

docs's Introduction

Atomist documentation

This repository contains the markdown sources for the documentation for Atomist. You can find the current version of the Atomist documentation at https://docs.atomist.com/.

The documentation is generated from markdown using MkDocs.

Editing

Much of the documentation is hand-generated, so you can feel free to edit.

We use the Google Developer Documentation Style Guide as our guide and suggest the Style guide highlights for a summary.

See below for instructions on how to test your changes locally.

You are not required to test your changes locally in order to contribute. Edit right on GitHub, and let Atomist (our build automation) take care of it.

Contribution criteria

Pull requests will be merged if they are better than the existing text. They don't need to be perfect.

Here's how I define better:

  • Out-of-date information is the worst.
  • Emptiness is better than inaccurate information.
  • Any (accurate) information is better than none.

Additional links and information are great.

We will move toward a consistent style and tone after merging.

Build and serve the documentation locally

Before you push changes to this repository, you may test your changes locally.

Instant Development environment

Docker

You can build the docs with the following command.

$ docker run -it --rm -v "$PWD:/docs" squidfunk/mkdocs-material:5.3.3 build --strict

You can also run htmltest.

$ docker run -it --rm -v "$PWD:/test" wjdp/htmltest:v0.12.0 htmltest

You can serve the docs with the following command.

$ docker run --rm -it -p 8000:8000 -v ${PWD}:/docs squidfunk/mkdocs-material:5.3.3

VS Code

If you open this repository in VSCode, and you have Docker, and you have the VSCode extension for remote containers, then VSCode will offer to open the folder in a container. Accept that, and you'll have a development environment with the right tools installed.

In the terminal inside VSCode, you can type

serve and then access your local, hot-reloading version of these docs on localhost:8000.

build will build the site and test the links.

You may now skip the rest of this section. Continue with [including code snippets from other repos][code-snippets]

macOS

Initial setup (and re-setup every time python gets updated).

$ rm -rf ~/.venvs/docs
$ mkdir -p !$
$ PIP_REQUIRE_VIRTUALENV=false pip3 install virtualenv
$ virtualenv ~/.venvs/docs

Initial install of htmltest.

$ tar -x -z -f htmltest_0.13.0_osx_amd64.tar.gz
$ install htmltest /usr/local/bin

Initialize virtualenv in your shell and install dependencies.

$ . ~/.venvs/docs/bin/activate
$ pip3 install -r requirements.txt

Actually build and serve the site.

$ mkdocs build --strict
$ htmltest
$ mkdocs serve

You can then access the local site at http://127.0.0.1:8000/ .

Styles

We use the Admonition extension to mkdocs. Here are the available admonition styles:

  • summary tldr
  • hint important tip
  • check done success
  • attention caution warning
  • fail failure missing
  • danger error
  • bug
  • default (i.e., none of the above)

Items on the same line create a visually equivalent admonition.

Buiding and Releasing

When a push is made to this repository, the documentation is built to https://docs.atomist.services using a CloudBuild trigger. The cloud build steps are in this cloudbuild.yaml file. In the atomist-web-docs-staging project, the cloudbuild service account has been given permission to deploy content updates to firebase. See instructions here.

When this repo is tagged, the documention is built to https://docs.atomist.com using a CloudBuild trigger. The steps for the cloud build are in this cloudbuild-prod.yaml.

Updating dependencies

The requirements.txt file sets specific versions for the packages. To update to new versions, you can use the following command:

$ ( cut -d = -f 1 requirements.txt > req.txt && \
      cat req.txt | xargs -n 1 pip install -U && \
      pip freeze -r req.txt > requirements.txt ) ; \
    rm req.txt

To update html-proofer and its dependencies:

$ bundle update

Conditions of use

This documentation build process is provided to the public purely for the purpose of testing documentation changes before submitting pull requests to the appropriate Atomist repository.

The documents produced by this build process may be published only on https://docs.atomist.com/. They may not be published in any other form or on any other website without explicit permission.


Created by Atomist. Need Help? Join our Slack workspace.

docs's People

Contributors

acolyer avatar alankstewart avatar alenkacz avatar atomist-bot avatar benjordan avatar cdupuis avatar claymccoy avatar dansmithy avatar ddgenome avatar errordeveloper avatar errrrk avatar geekflyer avatar gjtorikian avatar gotcha avatar ipcrm avatar janekdb avatar jessitron avatar jhuiting avatar jpwarren avatar jrday avatar kipz avatar lawouach avatar murban74 avatar neilprosser avatar russmiles avatar slimslenderslacks avatar stephenweber avatar whostolebenfrog avatar willgardella avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

docs's Issues

Document clj.yml configuration for authenticated repos

    publish: true
    url: "${MAVEN_BASE_URL}/rugs-dev"
    authentication:
      username: "${MAVEN_USER}"
      password: "${MAVEN_TOKEN}"

We need to add a section to the docs explaining how authentication can be configured in cli.yml.

Title + Header sometimes duplicated

The new layout, which is much better, includes the title of the page from the mkdocs.yml config at the top of the page. The old layout did not. Because the old layout did not, many pages have similar headers at the top of their source. For example:

intro-intro-intro

We need to go through mkdocs.yml config and make sure all the page titles are appropriate for displace in the page and go through all the pages and remove duplication between the page title and the initial header. I would guess we just need to remove most of the initial headers.

Add convention for when to name a type in a Rug DSL selector

For example if you are going to access the project from within a do block then you should name the selected type appropriately:

with file f when path = "README.md"
  do replace "{{creation_date}}" { f.name() + " created on " + new Date().toISOString().split('T')[0] }

However if the selected type is not being used then the name should be omitted:

with file when path = "README.md"
  do replace "{{creation_date}}" { new Date().toISOString().split('T')[0] }

Only push site for actual releases

Currently, every Travis build pushes to the public site. Fix the build to only push for GitHub releases. This involves update the Travis configuration to create GitHub releases for tags that look like M.N.P semantic versions.

See rug-cli for an example.

Split conventions into General, Rug DSL and Rug TypeScript

The current Rug Conventions document has grown considerably and is beginning to break the navigation rendering. One option here is to attempt to break things out based on general purpose, Rug DSL and Rug TypeScript specific conventions. This might also prove more scalable generally as other JavaScript-transpiled options become available for Rug.

Add rug conventions documentation

We need to capture standards and best practices in a document. Things like what is that parameter name format camelCase/CamelCase/snake_case/kebab-case, common/recommended annotations, etc.

The links in the left navigation box on the main page on do nothing

The "Just get me going right now: Quick Starts" and "I want to know more: Reference Documentation" in the left-hand navigation box presumably are meant to jump to sections within the page, but since the page fits in a single pane, clicking on them does nothing. They should either be changed go to the actual page or be removed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.