~sircmpwn/sr.ht-discuss

11 6

Building with multiple language versions

Details
Message ID
<796fec45-346e-490d-b28f-3a55a62e3cbc@www.fastmail.com>
DKIM signature
fail
Download raw message
DKIM signature: fail
I'm looking to move from Travis-CI to builds.sr.ht. One thing that
isn't clear to me is if it's possible to run several versions of a
language runtime for testing.

On Travis-CI, one can have a config like so:

    os: linux
    dist: bionic

    language: go
    go:
    - '1.13'
    - '1.14'
    - '1.15'

This will run `go test' on Go 1.13, 1.14, and 1.15. If any one of
them fails, the whole test fails. This essentially works as a set of
supported versions.

Is there some way to replicate this on builds.sr.ht? If I use a
manifest like this:

    image: alpine/edge
    packages:
    - go
    sources:
    - https://git.sr.ht/~ancarda/tls-redirector
    tasks:
    - info: go version
    - build: |
        cd tls-redirector
        go test -v

Only a single test will happen using Go 1.15. I did try running them
in a docker container, but that didn't work as I don't have root
access to start the docker daemon.

What can I do about this? I thought about having 1 manifest per
version/environment, and using the main `.build.yml' to trigger all
of them using the API. Would something like that be recommended?

-Mark
Details
Message ID
<C59Q0SJOUWRB.18CIW7F1NKAH0@homura>
In-Reply-To
<796fec45-346e-490d-b28f-3a55a62e3cbc@www.fastmail.com> (view parent)
DKIM signature
pass
Download raw message
On Sat Aug 29, 2020 at 3:17 PM EDT, Mark Dain wrote:
> Only a single test will happen using Go 1.15. I did try running them
> in a docker container, but that didn't work as I don't have root
> access to start the docker daemon.

You do have root access. Use sudo.
Details
Message ID
<4a3e5387-3f70-4c0f-835f-cf265f083206@www.fastmail.com>
In-Reply-To
<C59Q0SJOUWRB.18CIW7F1NKAH0@homura> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Sat, Aug 29, 2020, at 8:18 PM, Drew DeVault wrote:
> You do have root access. Use sudo.

Oh that's embarrassing, why didn't I try sudo!

Do you mean something like this:

    tasks:
    - 'go1_15': |
        cd tls-redirector
        sudo rc-service docker start    
        sudo docker run ...

It looks like Docker does start, but `docker run' still errors
with "Cannot connect to the Docker daemon". Is there anything
else that needs to be done?

The job is here: https://builds.sr.ht/~ancarda/job/290275
Details
Message ID
<C59QKJ2YKIQT.XR0NTN405BDM@homura>
In-Reply-To
<4a3e5387-3f70-4c0f-835f-cf265f083206@www.fastmail.com> (view parent)
DKIM signature
pass
Download raw message
I resubmitted this build with a `sleep 5` after starting docker and it
seems to work. I think it takes a moment for the daemon to completely
come online.
Details
Message ID
<48cc78b5-79eb-a932-40cf-5227ff87fd02@federated.id>
In-Reply-To
<C59QKJ2YKIQT.XR0NTN405BDM@homura> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On 8/29/20 9:43 PM, Drew DeVault wrote:
> I resubmitted this build with a `sleep 5` after starting docker and it
> seems to work. I think it takes a moment for the daemon to completely
> come online.
> 

I also use buildah for running containers. It still needs root access, 
but it does not require a daemon to be running.

This might be cleaner that way than having to introduce waiting times in 
the build.

/Marius
Details
Message ID
<7b006cf9-fc31-4d46-bb24-16560bd4dba3@www.fastmail.com>
In-Reply-To
<48cc78b5-79eb-a932-40cf-5227ff87fd02@federated.id> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Sun, Aug 30, 2020, at 9:24 AM, Marius Orcsik wrote:
> On 8/29/20 9:43 PM, Drew DeVault wrote:
> > I resubmitted this build with a `sleep 5` after starting docker and it
> > seems to work. I think it takes a moment for the daemon to completely
> > come online.
> 
> I also use buildah for running containers. It still needs root access, 
> but it does not require a daemon to be running.
> 
> This might be cleaner that way than having to introduce waiting times in 
> the build.
> 
> /Marius

Thanks, Marius, I'll take a look at buildah.

Sadly, I have had limited success getting Docker to work by
adding a delay. In some cases, 5 seconds seems to not be enough
time[1], but in other cases, the build server seems to get stuck
at the sleep command[2].

I wrote a small script[3] that periodically tries to call
`docker run' until it gets a successful exit code. It works
locally, but after far too long I had to cancel the build[4].
It seems like Docker didn't start properly.

Have you run into any problems like these using buildah? Would
you be willing to show me a working manifest I could use as a
foundation?

-Mark

[1] https://builds.sr.ht/~ancarda/job/290308
[2] https://builds.sr.ht/~ancarda/job/290294
[3] https://git.sr.ht/~ancarda/exp-srht-goci/tree/master/poll-docker.sh
[4] https://builds.sr.ht/~ancarda/job/290345
Details
Message ID
<C5AIFNPUG0Q1.3R47STBS1SBU5@45c1912b3bc6>
In-Reply-To
<7b006cf9-fc31-4d46-bb24-16560bd4dba3@www.fastmail.com> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Sun Aug 30, 2020 at 5:56 PM UTC, Mark Dain wrote:
> Thanks, Marius, I'll take a look at buildah.
>
> Sadly, I have had limited success getting Docker to work by
> adding a delay. In some cases, 5 seconds seems to not be enough
> time[1], but in other cases, the build server seems to get stuck
> at the sleep command[2].
>
> I wrote a small script[3] that periodically tries to call
> `docker run' until it gets a successful exit code. It works
> locally, but after far too long I had to cancel the build[4].
> It seems like Docker didn't start properly.

I use this sleep workaround for docker builds and they also get stuck
occasionally at the sleep command[0], my options are to cancel the build or
wait until it times out. Resubmitting the build manifest will succeed[1]
about 75% of the time.
I don't know why the build gets stuck here, I never discovered the reason

[0] https://builds.sr.ht/~aaronkelly/job/286166
[1] https://builds.sr.ht/~aaronkelly/job/290773
Details
Message ID
<92b3f8ef-8624-3122-220b-b02b887aa624@archlinux.org>
In-Reply-To
<796fec45-346e-490d-b28f-3a55a62e3cbc@www.fastmail.com> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On 8/29/20 3:17 PM, Mark Dain wrote:
> I'm looking to move from Travis-CI to builds.sr.ht. One thing that
> isn't clear to me is if it's possible to run several versions of a
> language runtime for testing.
> 
> On Travis-CI, one can have a config like so:
> 
>     os: linux
>     dist: bionic
> 
>     language: go
>     go:
>     - '1.13'
>     - '1.14'
>     - '1.15'
> 
> This will run `go test' on Go 1.13, 1.14, and 1.15. If any one of
> them fails, the whole test fails. This essentially works as a set of
> supported versions.
> 
> Is there some way to replicate this on builds.sr.ht? If I use a
> manifest like this:
> 
>     image: alpine/edge
>     packages:
>     - go
>     sources:
>     - https://git.sr.ht/~ancarda/tls-redirector
>     tasks:
>     - info: go version
>     - build: |
>         cd tls-redirector
>         go test -v
> 
> Only a single test will happen using Go 1.15. I did try running them
> in a docker container, but that didn't work as I don't have root
> access to start the docker daemon.
> 
> What can I do about this? I thought about having 1 manifest per
> version/environment, and using the main `.build.yml' to trigger all
> of them using the API. Would something like that be recommended?

Why do you need one build to trigger other builds, if the .builds/
directory exists?

An alternative that lets you use one build to run all the tests, is to
download each of the precompiled golang releases from
https://golang.org/dl/, then run multiple stages for the build, each
time extracting one toolchain to /usr/local and using that go version.
Unfortunately I don't think any distro currently provides all such
packages for you... travis does its own stuff to provide language runtimes.

Maybe it would be interesting to set up a repo containing various
language runtimes which people could enable and install in their
manifests. Though I don't know how well-behaved golang is about having
versioned executables like /usr/bin/go-1.5

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
Details
Message ID
<295adf52-c910-44ed-b494-4422b71ac10a@www.fastmail.com>
In-Reply-To
<92b3f8ef-8624-3122-220b-b02b887aa624@archlinux.org> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Mon, Aug 31, 2020, at 4:57 AM, Eli Schwartz wrote:
> On 8/29/20 3:17 PM, Mark Dain wrote:
> > What can I do about this? I thought about having 1 manifest per
> > version/environment, and using the main `.build.yml' to trigger all
> > of them using the API. Would something like that be recommended?
> 
> Why do you need one build to trigger other builds, if the .builds/
> directory exists?

Didn't know that was possible. It's mentioned in the man page
but I must have missed that.

> An alternative that lets you use one build to run all the tests, is to
> download each of the precompiled golang releases from
> https://golang.org/dl/, then run multiple stages for the build, each
> time extracting one toolchain to /usr/local and using that go version.
> Unfortunately I don't think any distro currently provides all such
> packages for you... travis does its own stuff to provide language runtimes.

I wasn't able to get this to work with Alpine for some reason,
but here it is working with Debian:

https://git.sr.ht/~ancarda/tls-redirector/tree/master/.builds
https://builds.sr.ht/~ancarda/job/291406

Thanks everyone for your help!

> Maybe it would be interesting to set up a repo containing various
> language runtimes which people could enable and install in their
> manifests. Though I don't know how well-behaved golang is about having
> versioned executables like /usr/bin/go-1.5

Go does have support for something like this:
https://golang.org/doc/install#extra_versions

Though, I have no idea how well it works in practice. I fear it
may subtly break as some tools may try to call out to `go' and
`gofmt' without realizing they are versioned.

-Mark
Details
Message ID
<C5B79FR9VW9U.1NS0LNQKN4QF8@homura>
In-Reply-To
<295adf52-c910-44ed-b494-4422b71ac10a@www.fastmail.com> (view parent)
DKIM signature
pass
Download raw message
Another option is to not build for multiple language versions. When was
the last time you caught something because of that? Build for the oldest
version you support.
Details
Message ID
<a3333189-9ea4-453a-a987-397723e2d124@www.fastmail.com>
In-Reply-To
<C5B79FR9VW9U.1NS0LNQKN4QF8@homura> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
FWIW, the last time I caught something like this was very recently. I
always support the last two releases of Go per their support policy, and
recently found a bug that occurred because of a change to the standard
library in Go 1.15. This also isn't a one off, it's fairly common for me
to find minor breakages between versions, especially in more complicated
packages like the net package. The recent preemption changes a version
or two ago also caused a lot of issues to be found that I wouldn't have
seen if I weren't running tests on a version that didn't have the
changes as well.

—Sam

On Mon, Aug 31, 2020, at 09:01, Drew DeVault wrote:
> Another option is to not build for multiple language versions. When
> was the last time you caught something because of that? Build for the
> oldest version you support.
>
Details
Message ID
<C5B7GPID1BZO.N6MX34YE2S9F@homura>
In-Reply-To
<a3333189-9ea4-453a-a987-397723e2d124@www.fastmail.com> (view parent)
DKIM signature
pass
Download raw message
Another approach is to use the oldest supported version and newest
supported version.
Reply to thread Export thread (mbox)