~sircmpwn/sr.ht-docs

655619212e4295430f6f8adc14b77a8e0db216f3 — Sol Fisher Romanoff 2 months ago 85fa43c
s/hyphen/em dash/g
M api-conventions.md => api-conventions.md +3 -3
@@ 70,7 70,7 @@ All requests and response bodies shall be encoded with Content-Type
Each resource returned by the API has its own schema, and may be given in two
forms: *full form* and *short form*. The full form is always returned when
retrieving a resource by ID, and contains the maximum amount of detail.  The
short form contains less information - an ID at the minimum, but often more -
short form contains less information — an ID at the minimum, but often more -
and is returned where the long form would be inconvenient, such as from a list
endpoint or for singletons embedded in a parent resource.



@@ 134,7 134,7 @@ versioning, each version being of the format "major.minor.patch". The patch
number increments with every release, the minor number increments when new
features are added, and the major version increments on breaking changes. Note
that the minor and patch versions may increment when changes are made to the web
frontend - which may not necessarily affect the API - but major versions only
frontend — which may not necessarily affect the API — but major versions only
increment on breaking API changes. Any API whose major version is 0 makes no
guarantees about interface stability.



@@ 184,7 184,7 @@ meta.sr.ht) `profile:update` or `ssh-key:remove`. These require the same OAuth
scopes to configure as are necessary to obtain these resources through polling -
there's no separate OAuth scope for webhooks.

Periodically polling the API is discouraged - use webhooks instead.
Periodically polling the API is discouraged — use webhooks instead.

### Webhook delivery


M builds.sr.ht/api.md => builds.sr.ht/api.md +2 -2
@@ 43,9 43,9 @@ Inserts a new job into the job queue.
                                  lowercase alphanumeric characters, or any
                                  of "-_." (optional)
  "execute": boolean,           True to start the build immediately
                                  (optional - defaults to true)
                                  (optional — defaults to true)
  "secrets": boolean,           True to provide secrets during the build
                                  (optional - defaults to true)
                                  (optional — defaults to true)
}
```


M builds.sr.ht/compatibility.md => builds.sr.ht/compatibility.md +1 -1
@@ 19,7 19,7 @@ The support lifecycle for each build image follows the upstream support cycle.
Each supported upstream release is generally offered on sr.ht, as well as the
bleeding edge or development releases if applicable. No sooner than two weeks
after a release becomes unsupported upstream, it will be unsupported on
builds.sr.ht - and anyone who's submitted recent builds using those images will
builds.sr.ht — and anyone who's submitted recent builds using those images will
get an email warning them of the impending breakage.

It's recommended that you use aliases like "alpine/latest" or "debian/testing"

M builds.sr.ht/configuration.md => builds.sr.ht/configuration.md +3 -3
@@ 56,7 56,7 @@ runner if you prefer). They need the following permissions:
  and read access to the user and secrets tables.

If you are running the master and runners on the same server, you will only be
able to use one user - the master user. Configure both the web service and build
able to use one user — the master user. Configure both the web service and build
runner with this account. Otherwise, two separate accounts is recommended.

Note: in the future runners will not have database access.


@@ 90,7 90,7 @@ directory.
A `build.yml` file is also provided for each image to build itself on your
build infrastructure once you have it set up, which you should customize as
necessary. It's recommended that you set up cron jobs to build fresh images
frequently - a script at `contrib/submit_image_build` is provided for this
frequently — a script at `contrib/submit_image_build` is provided for this
purpose.

**Note**: it is recommended that you modify our `build.yml` files to suit your


@@ 132,7 132,7 @@ In order to run builds, we require the following:
- SSH listening on port 22 (the standard port) with passwordless login *enabled*
- A user named `build` to log into SSH with, preferrably with uid 1000
- git config setting user.name to builds.sr.ht and user.email to builds@sr.ht
- Bash (temporary - we'll make this more generic at some point)
- Bash (temporary — we'll make this more generic at some point)

Not strictly necessary, but recommended:


M builds.sr.ht/index.md => builds.sr.ht/index.md +4 -4
@@ 28,12 28,12 @@ on.
# How jobs are submitted

Unlike some other build systems, builds.sr.ht does not let you configure builds
on the website itself. Instead, you write build *manifests* - YAML files that
on the website itself. Instead, you write build *manifests* — YAML files that
tell builds.sr.ht what to do. You can then submit these manifests via the API
and we'll assign a runner and execute your job.

For convenience, there are ways of submitting builds automatically throughout
the sr.ht ecosystem - for example by pushing to repositories on git.sr.ht.
the sr.ht ecosystem — for example by pushing to repositories on git.sr.ht.
These integrations are [discussed below](#integrations). For details on
submitting jobs via the API, see the [API reference](api.md).



@@ 55,7 55,7 @@ tasks:
When you submit this build, we'll fire up a virtual machine running an
up-to-date image of Alpine Linux. Then, we'll copy your scripts into the machine
and run them one at a time. More complex build jobs will probably use more
features of the build.yml - here's an example that deploys
features of the build.yml — here's an example that deploys
[web.synapse-bt.org](https://web.synapse-bt.org):

```yaml


@@ 201,7 201,7 @@ submitted, 4 manifests will be randomly chosen).
## hg.sr.ht

hg.sr.ht will also automatically submit builds for you. The naming conventions
and other details are the same as the process used by git.sr.ht - described
and other details are the same as the process used by git.sr.ht — described
above.

## hub.sr.ht

M builds.sr.ht/installation.md => builds.sr.ht/installation.md +2 -2
@@ 25,8 25,8 @@ On each server hosting a job runner, install the `builds.sr.ht-worker` and

## Daemons

- `builds.sr.ht` - The web service (master server).
- `builds.sr.ht-worker` - The job runner.
- `builds.sr.ht` — The web service (master server).
- `builds.sr.ht-worker` — The job runner.

## Configuration


M builds.sr.ht/private-repos.md => builds.sr.ht/private-repos.md +2 -2
@@ 4,7 4,7 @@ title: Private repos on builds.sr.ht

<div class="alert alert-danger">
  <strong>Warning!</strong> The list of commands run in a builds.sr.ht job, as
  well as their stdout and stderr, are visible to the public - even if the job
  well as their stdout and stderr, are visible to the public — even if the job
  uses a private repository. Take care not to leak any secrets this way.
</div>



@@ 15,7 15,7 @@ configure each job with an SSH key that has access to your account.
1. Add the public key [to your account](https://meta.sr.ht/keys)
1. Add the private key as a secret using the [secrets management page](https://builds.sr.ht/secrets)
1. Copy the secret's UUID into your build manifest's secrets list.
1. Update your sources list to use the SSH clone URL - not the https clone URL.
1. Update your sources list to use the SSH clone URL — not the https clone URL.

The resulting build manifest should look something like this:


M configuration.md => configuration.md +2 -2
@@ 25,7 25,7 @@ Before configuring any sr.ht service, ensure that you have the following
services installed. Every sr.ht service makes use of them, so your deployment
will likely not work as expected if they are missing.

- [core.sr.ht][core] - Provides functionality used by all sr.ht services.
- [core.sr.ht][core] — Provides functionality used by all sr.ht services.

    - For users installing from packages, this package is automatically pulled
      in as a dependency.


@@ 40,7 40,7 @@ will likely not work as expected if they are missing.
             class="alert-link">Alpine package</a>.
        </div>

- [meta.sr.ht][meta] - Performs various administrative tasks (e.g., storing
- [meta.sr.ht][meta] — Performs various administrative tasks (e.g., storing
  account details, handling logins, SSH and PGP key storage).

[meta]: https://git.sr.ht/~sircmpwn/meta.sr.ht

M dispatch.sr.ht/installation.md => dispatch.sr.ht/installation.md +1 -1
@@ 12,7 12,7 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `dispatch.sr.ht` - The web service.
- `dispatch.sr.ht` — The web service.

## Configuration


M git.sr.ht/api.md => git.sr.ht/api.md +1 -1
@@ 467,4 467,4 @@ executing `git push`. Your server has 5 seconds to respond to the HTTP request.
- Push options (specified via `git push -o <option>`) are interpreted as
  `key=value`, and the map is populated as such. For example, `git push -o
  foo=bar` would result in `{"foo": "bar"}`. Options specified without a value -
  e.g. `-o foo` - will have their value set to an empty string.
  e.g. `-o foo` — will have their value set to an empty string.

M git.sr.ht/index.md => git.sr.ht/index.md +1 -1
@@ 152,7 152,7 @@ git tag -a <tag name>
```

For example, `git tag -a 2.3.4` to tag version 2.3.4. Your text editor will
open, and you'll be prompted to *annotate* the tag - fill this in with release
open, and you'll be prompted to *annotate* the tag — fill this in with release
notes, a changelog, etc. Consider using
[`git-shortlog`](https://git-scm.com/docs/git-shortlog) to generate your
changelog.

M git.sr.ht/installation.md => git.sr.ht/installation.md +4 -4
@@ 12,13 12,13 @@ installation](/installation.md#installing-from-packages).

## Daemons

- `git.sr.ht` - The web service.
- `git.sr.ht-api` - The API service.
- `git.sr.ht-webhooks` - Webhook delivery service.
- `git.sr.ht` — The web service.
- `git.sr.ht-api` — The API service.
- `git.sr.ht-webhooks` — Webhook delivery service.

## Cronjobs

- `gitsrht-periodic` - Performs various maintenance tasks.
- `gitsrht-periodic` — Performs various maintenance tasks.

## Configuration


M git.sr.ht/send-email.md => git.sr.ht/send-email.md +2 -2
@@ 14,7 14,7 @@ https://git-send-email.io
## Tell people how to contribute

The first thing you need to do is help potential contributors figure out how to
contact you. The easiest way is to do nothing - git records your email with
contact you. The easiest way is to do nothing — git records your email with
every commit, so someone with a copy of your git repository can figure out how
to contact you. You'll probably want to make it a bit easier on them, though.



@@ 30,7 30,7 @@ When a patch comes in, you should review it carefully. Read the code, apply the
patch locally and make sure it compiles, test the changes, and so on. During
this process you'll probably come up with feedback on the patch. Pull open that
email client and compose a reply to the patch author. When your client composes
the reply, don't be afraid to slice and dice the email you're replying to - trim
the reply, don't be afraid to slice and dice the email you're replying to — trim
out the fat and only include specific lines that you want to comment on.

If you only have small comments here and there, feel free to make the changes

M graphql.md => graphql.md +1 -1
@@ 142,7 142,7 @@ query {
```

Each field adds 1 to your complexity, unless it represents a relationship like
sshKeys - in which case it is multiplied by the number of results you request.
sshKeys — in which case it is multiplied by the number of results you request.
The total complexity of your request is capped to 200 by default; some services
permit more.


M hg.sr.ht/email.md => hg.sr.ht/email.md +8 -8
@@ 28,15 28,15 @@ out, check out the [sr.ht-dev][sr.ht-dev] mailing list.
[sr.ht-dev]: https://lists.sr.ht/~sircmpwn/sr.ht-dev

Unsure if your setup is correct? Try sending the patch to sir@cmpwn.com for
feedback first - make sure you mention in the email that you want feedback.
feedback first — make sure you mention in the email that you want feedback.

# For contributors

## Preparing your changes

There's no need to "fork" the repository you want to contribute to -- simply use
There's no need to "fork" the repository you want to contribute to — simply use
[`hg clone`][hg-clone] to obtain a local copy of the mercurial repository and
[work normally][work-normally]. Be deliberate about your commits -- use
[work normally][work-normally]. Be deliberate about your commits — use
meaningful commit messages and take special care to commit your work in the form
of logically separate changes. When it comes time to review your work, your
commit history is an important tool for the reviewer and will be closely


@@ 48,10 48,10 @@ examined.
# Find out where to send your changes

This workflow is optional for projects hosted on sr.ht and each project will
have different requirements - review them carefully. To use this guide, you need
to find an email address to send your work to - this will often be a mailing
have different requirements — review them carefully. To use this guide, you need
to find an email address to send your work to — this will often be a mailing
list on [lists.sr.ht](/lists.sr.ht). You will also want to find people who can
help review your changes - look for dedicated maintainers for the modules you're
help review your changes — look for dedicated maintainers for the modules you're
working on, or use [`hg annotate`][hg-annotate] to find people who have recently
worked on similar code.



@@ 201,7 201,7 @@ any other value passed through the command-line.
## Tell people how to contribute

The first thing you need to do is help potential contributors figure out how to
contact you. The easiest way is to do nothing - mercurial records your email
contact you. The easiest way is to do nothing — mercurial records your email
with every commit, so someone with a copy of your mercurial repository can
figure out how to contact you. You'll probably want to make it a bit easier on
them, though.


@@ 218,7 218,7 @@ When a patch comes in, you should review it carefully. Read the code, apply the
patch locally and make sure it compiles, test the changes, and so on. During
this process you'll probably come up with feedback on the patch. Pull open that
email client and compose a reply to the patch author. When your client composes
the reply, don't be afraid to slice and dice the email you're replying to - trim
the reply, don't be afraid to slice and dice the email you're replying to — trim
out the fat and only include specific lines that you want to comment on.

If you only have small comments here and there, feel free to make the changes

M hg.sr.ht/installation.md => hg.sr.ht/installation.md +1 -1
@@ 12,7 12,7 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `hg.sr.ht` - The web service.
- `hg.sr.ht` — The web service.

## Cronjobs


M installation.md => installation.md +4 -4
@@ 48,14 48,14 @@ security vulnerabilities, and so on.

Most sr.ht services require the following:

- A [PostgreSQL](https://www.postgresql.org/) server - persistent storage
- A [PostgreSQL](https://www.postgresql.org/) server — persistent storage

- A [Redis](https://redis.io) server - ephemeral storage, caching, work
- A [Redis](https://redis.io) server — ephemeral storage, caching, work
  distribution

- A mail server - incoming/outgoing mail
- A mail server — incoming/outgoing mail

- A cron daemon - scheduled tasks
- A cron daemon — scheduled tasks

# Installing From Packages


M lists.sr.ht/configuration.md => lists.sr.ht/configuration.md +1 -1
@@ 13,7 13,7 @@ to accept SMTP and run on another server. See `config.ini` for details.

The LMTP daemon uses the same config file as the others, and there are some
options there specifically catered to it. The most important is the Unix socket
path for the LMTP socket - and the user/group it should be assigned to. Make
path for the LMTP socket — and the user/group it should be assigned to. Make
sure that this is readable and writable by your MTA.

Enable the `lists.sr.ht-lmtp` service and configure your MTA to forward emails

M lists.sr.ht/index.md => lists.sr.ht/index.md +1 -1
@@ 107,7 107,7 @@ fine-grained enough to support many access scenarios, here are some examples:
## Announcement lists

A list that only you can write to is useful for announcements. Remove all user's
"post" and "reply" permissions to prevent them from submitting - owners are
"post" and "reply" permissions to prevent them from submitting — owners are
always able to post. You can optionally leave the "reply" permission enabled to
allow people to respond to announcements, but be aware that their responses will
be sent out to all subscribers, which is usually undesirable for low-volume

M lists.sr.ht/installation.md => lists.sr.ht/installation.md +4 -4
@@ 12,10 12,10 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `lists.sr.ht` - The web service.
- `lists.sr.ht-lmtp` - Incoming mail service.
- `lists.sr.ht-process` - Mail processing service.
- `lists.sr.ht-webhooks` - Webhook delivery service.
- `lists.sr.ht` — The web service.
- `lists.sr.ht-lmtp` — Incoming mail service.
- `lists.sr.ht-process` — Mail processing service.
- `lists.sr.ht-webhooks` — Webhook delivery service.

## Configuration


M man.sr.ht/index.md => man.sr.ht/index.md +1 -1
@@ 35,7 35,7 @@ are:

Publishing your changes is as easy as committing them and pushing them
upstream. You can collaborate with others on your wiki the same way you
do on your git.sr.ht projects - a mailing list on lists.sr.ht or
do on your git.sr.ht projects — a mailing list on lists.sr.ht or
any other approach that you like.

## Settings

M man.sr.ht/installation.md => man.sr.ht/installation.md +1 -1
@@ 16,7 16,7 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `man.sr.ht` - The web service.
- `man.sr.ht` — The web service.

## Configuration


M meta.sr.ht/installation.md => meta.sr.ht/installation.md +3 -3
@@ 17,9 17,9 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `meta.sr.ht` - The web service.
- `meta.sr.ht-api` - The API service.
- `meta.sr.ht-webhooks` - Webhook delivery service.
- `meta.sr.ht` — The web service.
- `meta.sr.ht-api` — The API service.
- `meta.sr.ht-webhooks` — Webhook delivery service.

## Cronjobs


M meta.sr.ht/oauth-api.md => meta.sr.ht/oauth-api.md +4 -4
@@ 59,11 59,11 @@ Provide the following parameters in the query string:
    <dt>client_id</dt>
    <dd>The client ID assigned to you in the previous step.</dd>
    <dt>scopes</dt>
    <dd>A list of scopes you're requesting - see next section.</dd>
    <dd>A list of scopes you're requesting — see next section.</dd>
    <dt>state</dt>
    <dd>Optional: an arbitrary string - see notes.</dd>
    <dd>Optional: an arbitrary string — see notes.</dd>
    <dt>redirect_uri</dt>
    <dd>Optional: your application URI for redirect the user to - see notes.</dd>
    <dd>Optional: your application URI for redirect the user to — see notes.</dd>
</dl>

The optional `state` field is returned to you after the redirect. One example


@@ 112,7 112,7 @@ some additional query string parameters you can use for the next steps:
    <dt>scopes</dt>
    <dd>The list of OAuth scopes the user consented to.</dd>
    <dt>error</dt>
    <dd>If present, indicates that an error occurred in the process - see notes.</dd>
    <dd>If present, indicates that an error occurred in the process — see notes.</dd>
    <dt>details</dt>
    <dd>If present, a human friendly error string, if that human is an engineer.</dd>
</dl>

M ops/backups.md => ops/backups.md +1 -1
@@ 30,7 30,7 @@ report to the [ops mailing list][ops ml].
   ensure that our snapshots are actually being taken.
2. Investigate something like [repospanner](https://github.com/repoSpanner/repoSpanner)
   to block git pushes until the data is known to be received and stored across
   multiple servers - would make git backups real-time
   multiple servers — would make git backups real-time

# Off-site backups


M ops/monitoring.md => ops/monitoring.md +1 -1
@@ 14,7 14,7 @@ Our Prometheus instance is publically available at
1. We should make dashboards. It would be pretty to look at and could be a
   useful tool for root cause analysis. Note that some users who have their own
   Grafana instance have pointed it at our public Prometheus data and made some
   simple dashboards - I would be open to having community ownership over this.
   simple dashboards — I would be open to having community ownership over this.

# Pushgateway


M ops/new-sysadmin.md => ops/new-sysadmin.md +1 -1
@@ 31,6 31,6 @@ the correct account? Is the email they sent DKIM signed and verified from the
right sender? If in doubt, ask for a secondary form of authentication, such as a
PGP challenge.

This also applies to normal requests from users - don't let someone impersonate
This also applies to normal requests from users — don't let someone impersonate
another user in an attempt to gain access to or manipulate their account. Be
especially careful with requests from users with 2FA enabled.

M ops/provisioning.md => ops/provisioning.md +1 -1
@@ 44,5 44,5 @@ This configuration supports up to 16 parallel build slots.

# Virtual machines

There is no standard loadout - tune the specifications for the task at hand.
There is no standard loadout — tune the specifications for the task at hand.
Generally limit 1 VM == 1 service, and tune accordingly.

M pages.sr.ht/installation.md => pages.sr.ht/installation.md +1 -1
@@ 14,7 14,7 @@ installation](/installation.md#installing-from-packages).

## Daemons

- `pages.sr.ht` - The web and API service.
- `pages.sr.ht` — The web and API service.

## Configuration


M paste.sr.ht/installation.md => paste.sr.ht/installation.md +1 -1
@@ 11,4 11,4 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `paste.sr.ht` - The web service.
- `paste.sr.ht` — The web service.

M privacy.md => privacy.md +1 -1
@@ 69,7 69,7 @@ give us, including (but not limited to):

To faciliate automated access to your account for third-party service or your
personal use, we also generate and store API keys which can be used to authorize
use of your account. A portion of these keys are stored in plaintext - not
use of your account. A portion of these keys are stored in plaintext — not
enough to gain access to your account, but enough for us to quickly look up your
account details given the key. The full key is stored only after processing with
bcrypt, similar to the process used for your password.

M todo.sr.ht/installation.md => todo.sr.ht/installation.md +3 -3
@@ 12,9 12,9 @@ installation process](/installation.md#installing-from-packages).

## Daemons

- `todo.sr.ht` - The web service.
- `todo.sr.ht-lmtp` - Incoming mail service.
- `todo.sr.ht-webhooks` - Webhook delivery service.
- `todo.sr.ht` — The web service.
- `todo.sr.ht-lmtp` — Incoming mail service.
- `todo.sr.ht-webhooks` — Webhook delivery service.

## Configuration


M tutorials/builds.sr.ht/github-integration.md => tutorials/builds.sr.ht/github-integration.md +4 -4
@@ 25,7 25,7 @@ tasks:
This is a build manifest, written in [YAML](http://yaml.org/). When we submit
this to builds.sr.ht, it will boot up an [Alpine
Linux](https://alpinelinux.org/) virtual machine using the edge release of
Alpine Linux. Then it will execute each of our build tasks - in this case,
Alpine Linux. Then it will execute each of our build tasks — in this case,
saying "hello world".

## Submitting jobs on the web


@@ 68,13 68,13 @@ Before starting your tasks, builds.sr.ht will clone each repository listed in
"sources" to the build environment. You can have as many or as few (including
zero) git repositories as you like. builds.sr.ht will also install [Alpine
Linux's meson package][meson] before starting your build. This uses Alpine's
native `apk` package manager - other images use different package managers.
native `apk` package manager — other images use different package managers.

[meson]: https://pkgs.alpinelinux.org/package/edge/main/x86_64/meson

## Testing on other platforms

Portability is important - so let's try running the same manifest on another
Portability is important — so let's try running the same manifest on another
operating system.

```yaml


@@ 101,7 101,7 @@ different names for packages, different distributions of coreutils, and so on.
## Adding these builds to your GitHub repository

Try making a new "mrsh" repository on your GitHub account. Note that forks won't
work - so make sure you make a *new* repository and push the mrsh code to it.
work — so make sure you make a *new* repository and push the mrsh code to it.
Take a look at the `.builds` directory in mrsh: each of these build manifests
can be submitted on push or pull request by rigging up a dispatch.sr.ht task.


M tutorials/builds.sr.ht/using-build-secrets.md => tutorials/builds.sr.ht/using-build-secrets.md +5 -5
@@ 23,7 23,7 @@ tasks:
    rsync -r example.org/* example.org:/var/www/
```

This is straightforward enough - but it won't work because the build won't have
This is straightforward enough — but it won't work because the build won't have
authorization to log into example.org.

## Generating the secrets & preparing our server


@@ 54,7 54,7 @@ next step.

Go to the [builds.sr.ht secret management
dashboard](https://builds.sr.ht/secrets) and select "SSH key" for secret type,
then paste your key into the text box. Click "submit" - and your new secret
then paste your key into the text box. Click "submit" — and your new secret
should show up on the right, along with its UUID.

This UUID is used to uniquely identify this secret in build manifests. Copy this


@@ 80,7 80,7 @@ tasks:

It's as easy as that! builds.sr.ht will install this SSH key into your build
environment when you submit this build manifest. However, it will only work for
builds submitted with your user - if someone else copies and pastes this build
builds submitted with your user — if someone else copies and pastes this build
manifest, the SSH key will not be added to their build VM.

## Controlling the use of secrets


@@ 89,13 89,13 @@ The easiest way to control whether or not secrets work in your build is by
turning them off via the API: if you set secrets=false in [POST
/api/jobs](/builds.sr.ht/api.md#post-apijobs), the secrets will not be resolved.
This is automatically done in many places where the build manifest could be
modified by an untrusted party - for example, dispatch.sr.ht disables secrets
modified by an untrusted party — for example, dispatch.sr.ht disables secrets
when submitting build manifests from GitHub pull requests.

However, some degree of responsibility lies with you for keeping your secrets
secure. Avoid writing build manifests that would print your secrets to the logs,
particularly if using file secrets. If a secret is ever leaked in this manner,
you should consider that secret compromised - revoke it and generate a new one.
you should consider that secret compromised — revoke it and generate a new one.

---


M tutorials/getting-started-with-builds.md => tutorials/getting-started-with-builds.md +3 -3
@@ 24,7 24,7 @@ tasks:
This is a build manifest, written in [YAML](http://yaml.org/). When we submit
this to builds.sr.ht, it will boot up an [Alpine
Linux](https://alpinelinux.org/) virtual machine using the edge release of
Alpine Linux. Then it will execute each of our build tasks - in this case,
Alpine Linux. Then it will execute each of our build tasks — in this case,
saying "hello world".

## Submitting jobs on the web


@@ 93,12 93,12 @@ tasks:

This time, builds.sr.ht will install [Alpine Linux's meson
package](https://pkgs.alpinelinux.org/package/edge/main/x86_64/meson) before
starting your build. This uses Alpine's native `apk` package manager - other
starting your build. This uses Alpine's native `apk` package manager — other
images use different package managers.

## Testing on other platforms

Portability is important - so let's try running the same manifest on another
Portability is important — so let's try running the same manifest on another
operating system.

```yaml

M tutorials/set-up-account-and-git.md => tutorials/set-up-account-and-git.md +2 -2
@@ 20,7 20,7 @@ need to set up your SSH key and add it on the keys page.
## Generating an SSH key

sr.ht does not support pushing to git repositories over HTTPS with a
username+password - SSH keys are mandatory. If you already have an SSH key, you
username+password — SSH keys are mandatory. If you already have an SSH key, you
can skip this step. If not, run the following command to generate one:

    ssh-keygen


@@ 75,7 75,7 @@ master branch to git.sr.ht:
    git push -u origin master

Since this repository didn't previously exist, you'll be prompted with a link to
create the repository on git.sr.ht - click that link and fill out the form on
create the repository on git.sr.ht — click that link and fill out the form on
that page. You'll be redirected to your repository on git.sr.ht: you're done!

<div class="alert alert-primary">

M tutorials/set-up-account-and-hg.md => tutorials/set-up-account-and-hg.md +2 -2
@@ 19,7 19,7 @@ need to set up your SSH key and add it on the keys page.
## Generating an SSH key

sr.ht does not support pushing to Mercurial repositories over HTTPS with a
username+password - SSH keys are mandatory. If you already have an SSH key, you
username+password — SSH keys are mandatory. If you already have an SSH key, you
can skip this step. If not, run the following command to generate one:

    ssh-keygen


@@ 68,7 68,7 @@ Run the following command to push your changes to hg.sr.ht:
    hg push ssh://hg@hg.sr.ht/~{{{srht_username}}}/example

Since this repository didn't previously exist, you'll be prompted with a link to
create the repository on hg.sr.ht - click that link and fill out the form on
create the repository on hg.sr.ht — click that link and fill out the form on
that page. You'll be redirected to your repository on hg.sr.ht: you're done!

You can save yourself some typing and just run `hg push` next time by adding