Sync common files between otel repos

[zeitlinger]

Why:

• github actions can get quite complicated - and many tasks such as link checking are not that different between repos
• some things, such as code of conduct, should be uniform across every repo

How:

• Prometheus has a script that we can take as a starting point: The sync script is called from a gh action.
• We can also have a list of opt-in repos that participate - maybe just for some of the fancy stuff

Where:

In OTel, there is no natural primary repo, but we can pick any repo that is well maintained, e.g. otel collector.

In case of questions: ask in prometheus-dev

[mx-psi]

For Github actions, would it make sense to package and publish Github actions that are then used by all other repositories?

[zeitlinger]

@trask the lychee setup at https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/.github/workflows/reusable-link-check.yml sounds like a good candidate for a custom gh action - "opentelemetry/link-check-action" (or lychee-action) could be a repo

[trask]

@trask the lychee setup at https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/.github/workflows/reusable-link-check.yml sounds like a good candidate for a custom gh action - "opentelemetry/link-check-action" (or lychee-action) could be a repo

I'd suggest trying it out in a personal repo first

[zeitlinger]

@trask the lychee setup at https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/.github/workflows/reusable-link-check.yml sounds like a good candidate for a custom gh action - "opentelemetry/link-check-action" (or lychee-action) could be a repo

I'd suggest trying it out in a personal repo first

I'm thinking it may be overkill - mise tasks can be synced quite easily - and we can use them for link checking, maybe even more

[svrnm]

FYI, it is possible to call a github action file from another repo, we did this back at Cisco OSPO with the scorecard action:

https://github.com/cisco-open/app-simulator/blob/main/.github/workflows/scorecard.yml#L20

references

https://github.com/cisco-ospo/.github/blob/main/.github/workflows/_scorecard.yml

So we could have some of the common actions centralized, without the overhead of keeping files in sync, which comes with a lot of complexity based on the experience we have with it in the dotio repo where we have a bunch of automations that try to keep things in sync.

[zeitlinger]

One challenge with packaging the lychee task (maybe others as well) is that lose the feature that you can easily run the same lychee task locally, because it's managed by mise, e.g. in java contrib.

Instead of syncing the task file, we could also fetch the task file via http.

[thompson-tomo]

I have been thinking about this while I was setting up cspell on the spec repo.

What are people's thoughts about using vendir from carvel?

My idea on how it could be used is:

• Have a central repo to store common text files
• Repo produces releases containing shared files
• Renovate is used to update the assets version as per the example
• the otel bot runs on the pr and performs the sync command. The sync downloads the file to a .vendir directory, copies the desired files to the necessary location within the repo. These changes are added to the renovate pr.