Pipeline & publishing

A cratly website is a repository of content. The pipeline turns that content into the website and puts it online, and the editor relies on it for three things.

Preview. A draft gets a preview button once its pipeline has succeeded — the finished site, built from that draft, before anyone else sees it.

Mistakes in a page, shown to whoever wrote it. Every build writes a report of what it found: a link pointing at a page that is not there, an image whose file is gone. The editor reads that report and names the page and the link.

Publication. The deploy step carries the approved state onto the web server.

Setting it up

The pipeline is one file in your repository, .gitlab-ci.yml, and it does not have to be written. Four templates are published; a site includes two of them — one to build, one to publish the way its hosting expects.

include:
	- remote: 'https://cratly.io/ci/v1/build.yml'
	- remote: 'https://cratly.io/ci/v1/deploy-s3.yml'
	  inputs:
		bucket: example.com

The pipeline reference covers the rest: the four templates, what each one takes, and what each publishing method can promise while a site is being replaced.

A site started from a site template already has this file. There the work is filling in where it publishes to.

Credentials

The deploy step needs whatever reaches your web server: an endpoint and keys for object storage, or a host, a user and a key for a server. They belong in the repository's CI/CD variables, marked as masked, and never in the file itself. The reference lists them per publishing method.

Publishing over SSH or SFTP needs one more: SSH_KNOWN_HOSTS, the target's host key, produced once with ssh-keyscan your-host.example.com. Without it a publication would trust whatever answers at that address.

While a draft is open

The editor shows each draft's pipeline status. A failing build stops the publication, and where the cause is a mistake in a page, the report turns it into something the author can correct.