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
140
141
142
|
---
title: Getting started with builds.sr.ht
---
builds.sr.ht is our build automation platform. We're going to walk through the
process of running jobs on builds.sr.ht and a look at a few useful features.
## Build manifests
Unlike platforms like Jenkins, builds.sr.ht does not allow you to pre-configure
jobs. And unlike platforms like Travis, jobs are not inherently tied to a git
repository. Each job on builds.sr.ht is described ad-hoc with a build manifest,
which can be submitted to builds.sr.ht for processing.
Let's start with a basic manifest:
```yaml
image: alpine/edge
tasks:
- example: |
echo "hello world"
```
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,
saying "hello world".
## Submitting jobs on the web
builds.sr.ht has a web submission form, where you can paste a build manifest and
submit the job without any additional configuration. This is a useful way of
testing build manifests before giving them a permanent home, or running one-off
tasks. Visit the [job submission form](https://builds.sr.ht/submit) and paste in
the example manifest. Add a note, perhaps "my first job", and click "submit" to
run the job.
You'll be redirected to the job detail page. In a moment, one of our job runners
will pick up the task and start processing it. Within a few seconds, you should
see "hello world" shown under the "example" task.
## Adding git repositories to builds
Let's try a new build manifest. This one is going to compile and test the
[scdoc](https://git.sr.ht/~sircmpwn/scdoc) project.
```yaml
image: alpine/edge
sources:
- https://git.sr.ht/~sircmpwn/scdoc
tasks:
- build: |
cd scdoc
make
- test: |
cd scdoc
make check
```
<div class="alert alert-warning">
<strong>Using Mercurial?</strong> Use `hg+https` and `hg.sr.ht` for the source
URL.
</div>
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.
## Adding dependencies
scdoc is a simple project with no dependencies. Let's try a slightly more
complex one: [mrsh](https://git.sr.ht/~emersion/mrsh), which depends on
[meson](https://mesonbuild.com/). Here's a build manifest for it:
```yaml
image: alpine/edge
packages:
- meson
sources:
- https://git.sr.ht/~emersion/mrsh
tasks:
- configure: |
cd mrsh
meson build
- build: |
cd mrsh
ninja -C build
- test: |
cd mrsh
ninja -C build test
```
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
images use different package managers.
## Testing on other platforms
Portability is important — so let's try running the same manifest on another
operating system.
```yaml
image: freebsd/latest
packages:
- meson
sources:
- https://git.sr.ht/~emersion/mrsh
tasks:
- configure: |
cd mrsh
meson build
- build: |
cd mrsh
ninja -C build
- test: |
cd mrsh
ninja -C build test
```
This one happens to work without any changes, but note that some images have
different names for packages, different distributions of coreutils, and so on.
## Adding these builds to your git repository
If you put a build manifest in `.build.yml` at the top of your repo, a build job
will be created each time you push new commits. You can also create multiple
manifests, for example to test multiple platforms, by putting several build
manifests at `.builds/*.yml`.
---
<div class="alert alert-info">
<strong>Want to learn more about builds.sr.ht?</strong>
Check out all of our <a href="/tutorials/builds.sr.ht">builds.sr.ht tutorials</a>.
</div>
Other resources:
- [builds.sr.ht user manual](/builds.sr.ht)
- [Build manifest reference](/builds.sr.ht/manifest.md)
|
