search

open-telemetry / opentelemetry-collector-releases

OpenTelemetry Collector Official Releases
https://opentelemetry.io
Apache License 2.0
251 stars 161 forks source link

Add nightly linux package tests #659

Open mowies opened 2 months ago

mowies commented 2 months ago

Description

Create a nightly version of the linux package tests that use the latest snapshots of main branch of core and contrib distributions from the respective repos.

This is a follow-up to https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/34372

mowies commented 2 months ago

i'd like to work on this, pls assign me :)

mowies commented 1 month ago

I started implementing this but hit some road blocks it seems. I tried building the otelcol-contrib on the spot while setting all component versions to main to do a fully up-to-date main branch build. Turns out, that comes with some complications and really really long build times (~45m to 1h). After some more thinking I came up with a better solution: Use the already built artifacts that are attached to every main branch build in the contrib repo (e.g. artifacts from this build) and then just build the linux packages from that with the actual distribution files from the releases repo.

There are 2 options on where to do this:

would be cool to get some feedback on this, maybe from @andrzej-stencel or @mx-psi or @codeboten

mx-psi commented 1 month ago

that comes with some complications and really really long build times (~45m to 1h)

Do we know (or can we know) why that is the case? Is it downloading dependencies that takes too long? Cloning the repo? The build process itself?

Use the already built artifacts that are attached to every main branch build in the contrib repo (e.g. artifacts from this build) and then just build the linux packages from that with the actual distribution files from the releases repo.

One downside of this is that these artifacts do not necessarily reflect the build time options we use here, but for testing it feels like they should be a net positive

run tests nightly in releases repo and have a github token with proper permissions to download the artifacts from contrib repo

I would prefer this, I'd like to keep anything related to linux package files on this repository

mowies commented 3 weeks ago

Do we know (or can we know) why that is the case? Is it downloading dependencies that takes too long? Cloning the repo? The build process itself?

From what I could gather, it's trying to fetch the latest main version from the Go proxy and waits for minutes until finally getting back a 404, then going to the github repo and downloading the whole thing from there, which is not a small download either. And I don't think lots of things are cached either in-between dependencies, so it does the whole process over and over.

I would prefer this, I'd like to keep anything related to linux package files on this repository

sounds good, then I'll continue in this direction

mowies commented 1 week ago

New status on this: I'll use the prebuilt builder from goreleaser pro which lets you split a goreleaser job into build and package/archive/docker/rest. This let's us either use the latest contrib collector binary from main branch or build it as usual from scratch.

the only downside is that maintainability will suffer a bit since the contrib goreleaser config is split into 2 files. But I think this is the only sensible approach after also speaking with goreleaser maintainers (https://github.com/goreleaser/goreleaser/issues/5234).