Move package testing to this repository

[mx-psi]

We have some package tests on opentelemetry-collector-contrib that should instead live here, since this is where we produce the packages and we do not have a mechanism to keep track of changes to the package scripts or systemd service definitions.

See open-telemetry/opentelemetry-collector-contrib/pull/29286 for context

[Enzujp]

hey @mx-psi , has this been resolved yet, and would you like for me to give it a go with your guidance of course ?

[mx-psi]

@Enzujp this has not been resolved. It's probably a bit harder than #498, but I am happy to help if you have specific questions :)

[Enzujp]

Hii @mx-psi , @ so I've gone through conversations from open-telemetry/opentelemetry-collector-contrib#29286 and, through the buildscripts dir . Moving package testing to this repository would require making edits to almost all individual files within buildscripts since most of its configurations are set to the opentelemetry-collector-contrib repo.
Am I right ?

[mx-psi]

@Enzujp yes, you are right! And in general: this may not be a trivial task, these tests have not been modified for a long time and a long has changed since

[Enzujp]

I'm trying out solutions to automate the release notes, should be done soon; and then I'd come back and we can map out doing this together?. :)

[mx-psi]

@Enzujp Sure! I am out until next week, but feel free to Slack me on the CNCF Slack (you can find my name on my profile :))

[mowies]

I think the way to go here would be to basically remove most if not all of the content in https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/internal/buildscripts/packaging/fpm and move just the test script over to the releases repo. All other files already exist in the -releases repo since the linux service packages are already built there anyways.
Then, a snapshot release could be built using the already existing makefile targets over in the -releases repo to build the packages that need to be tested.

@mx-psi WDYT? I'd give this a shot if it makes sense to you.

[jpkrohling]

Then, a snapshot release could be built using the already existing makefile targets over in the -releases repo to build the packages that need to be tested.

Sounds good to me. I would prefer this to be a new workflow, triggered only when the goreleaser files are changed, and tested only on cherry-picked combinations.

[mx-psi]

This makes sense to me, and agreed on the new workflow triggered by goreleaser files changed

[mowies]

Sounds good to me. I would prefer this to be a new workflow, triggered only when the goreleaser files are changed, and tested only on cherry-picked combinations.

Sure then let's start with the most commonly used one, which is probably Linux amd64?
New workflow sounds good, but I guess it should also trigger on change for any of the service unit files (e.g. also pre/post install scripts etc.).

[mowies]

I'll get to it then 🚀

[mowies]

@jpkrohling I looked into it a bit more and found out that the package tests could nicely fit into the current ci-goreleaser workflows. They already trigger on the right changes and build a snapshot release. We would just need to upload the packages to test as artifacts and then trigger the package test workflow right after and use the artifacts there.

So the https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/.github/workflows/base-ci-goreleaser.yaml workflow would get a step at the end (in pseudocode):

if: goos is linux and goarch is amd64
uses: actions/upload-artifact
with: the-correct-rpm/deb/apk-files-to-upload

and then the package-test workflow would be called after e.g. https://github.com/open-telemetry/opentelemetry-collector-releases/blob/main/.github/workflows/ci-goreleaser-core.yaml#L34 and use the artifact for testing

[jpkrohling]

Sounds good to me.

[mowies]

PR is ready for review 🚀