1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
---
title: builds.sr.ht docs
---
[builds.sr.ht](https://builds.sr.ht) is a service on sr.ht that allows you to
submit "build manifests" for us to work on. We spin up a virtual machine per
your specifications and run your scripts in it. This is generally used to
compile and test patches, deploy websites, build and publish packages, and so
on.
**See also**:
- [API reference](api.md)
- [Installation guide](installation.md)
# 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
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.
These integrations are [discussed below](#integrations). For details on
submitting jobs via the API, see the [API reference](api.md).
## Build manifests
Build manifests are YAML files that contain a description of your build
environment and steps to run in that environment. A very simple example could
be:
```yaml
image: alpine/edge
tasks:
- say-hello: |
echo hello
- say-world: |
echo world
```
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
[web.synapse-bt.org](https://web.synapse-bt.org):
```yaml
image: archlinux
packages:
- nodejs
- npm
- rsync
sources:
- https://git.sr.ht/~sircmpwn/receptor
environment:
deploy: synapse@synapse-bt.org
secrets:
- 7ebab768-e5e4-4c9d-ba57-ec41a72c5665
tasks:
- setup: |
cd receptor
npm install
- build: |
cd receptor
npm run build:production
- deploy: |
cd receptor
sshopts="ssh -o StrictHostKeyChecking=no"
rsync --rsh="$sshopts" -rP index.html $deploy:/var/www/web.synapse-bt.org/
rsync --rsh="$sshopts" -rP dist $deploy:/var/www/web.synapse-bt.org/
```
A [full reference](manifest.md) for build manifests is available.
## Build images
View the full list of [supported build images](compatibility.md).
## Secrets
builds.sr.ht can keep track of secrets for you, like SSH keys or PGP keys, and
include them in builds for the purpose of deployment. You can manage your
secrets at the [secrets dashboard](https://builds.sr.ht/secrets). Each secret
will only be included in the runtime image if the job was submitted using an
OAuth key which has access to the secrets specified in the build manifest.
## Build environment
Each task's script is given a preamble that looks like this:
```sh
#!/usr/bin/env bash
. ~/.buildenv
set -x
set -e
```
The actual shell varies depending on your build image. `~/.buildenv` contains
the environment variables you specified in your manifest, but feel free to
modify it to communicate state between build steps.
# Build status badges
If you add tags to your build, or enter search terms, you can use these to
create a build status badge like this (the example being the latest status of
builds.sr.ht itself):
[](https://builds.sr.ht/~sircmpwn/builds.sr.ht?)
The image URL and a markdown snippet are shown in the sidebar of the [search
results page](https://builds.sr.ht/~sircmpwn?search=scheduled+image+refresh) or
[tag detail page](https://builds.sr.ht/~sircmpwn/builds.sr.ht).
# Integrations
Do you have something that integrates with builds.sr.ht? Submit a patch for this
page!
## dispatch.sr.ht
[dispatch.sr.ht](https://dispatch.sr.ht) offers a variety of integrations with
builds.sr.ht, including support for connecting builds.sr.ht to external services
like GitHub. This should be your first stop when looking for an integration.
## git.sr.ht
git.sr.ht will automatically submit builds for you if you store a manifest in
the repository as `.build.yml`. Each time you push, a build with this manifest
will be submitted. If the repo you pushed to is present in the manifest's
sources array, we'll edit it to point to the ref you just pushed. You can also
submit several builds on each push by providing `.builds/*.yml`.
## 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
above.
|
