REQUEST: Repository maintenance on opentelemetry-dotnet & opentelemetry-dotnet-contrib

[CodeBlanch]

Affected Repository

• https://github.com/open-telemetry/opentelemetry-dotnet
• https://github.com/open-telemetry/opentelemetry-dotnet-contrib

Requested changes

I have three things I need done. See Purpose section for details.

• I have a GitHub App named "OpenTelemetry .NET Automation". I want to transfer this to the open-telemetry organization. Someone with admin will need to approve this.
• Once transferred to open-telemetry org I need an admin to give @open-telemetry/dotnet-maintainers access to manage that app. This way all currently/future maintainers will have access.
• I need this app installed into opentelemetry-dotnet & opentelemetry-dotnet-contrib. Admin may need to do that or the manage access might be enough for maintainers to do this.

Purpose

I am working on automating the release process and a bunch of maintenance tasks for dotnet. There are a lot of steps. We open PRs. Create Releases. Push tags. Invoke workflows in contrib repo.

The challenge is when these things are done via GitHub actions they don't trigger other workflows. There are a few recommendations published by GitHub to solve this: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#workarounds-to-trigger-further-workflow-runs

The one I am attempting to implement with this app is: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#authenticating-with-github-app-generated-tokens

I don't like the Personal Access Token (PAT) approach because everything will look like it is being done by a person (probably me) and the tokens expire. SSH key only works for pushes. Machine account won't work for kicking off workflows in contrib.

The release process is like this (noted where tokens will help)...

• Workflow is manually invoked to kick things off. A tag\version is chosen.
• Workflow opens a PR to update CHANGELOGs and public api files. A token is needed here so this PR triggers a CI workflow.
• A maintainer has to merge this PR.
• Once the release PR is merged another workflow creates a tag. A token is needed here to trigger workflows which spawn on tag push.
• A release workflow triggers on the tag push and creates a github release. A token is needed here to trigger workflows which spawn on release publish.
• A release workflow triggers on the release publish. It performs these actions...
  • A cleanup PR is opened to update some metadata for the latest version. A token is needed here to trigger CI workflow on that PR.
  • We call a workflow in contrib to notify it of the new release. That workflow kicks off a similar process in contrib. A token is needed here to call into contrib.

Expected Duration

Permanent

Repository Maintainers

@open-telemetry/dotnet-maintainers

[trask]

The challenge is when these things are done via GitHub actions they don't trigger other workflows. There are a few recommendations published by GitHub to solve this: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#workarounds-to-trigger-further-workflow-runs

would this work for you? https://github.com/open-telemetry/community/blob/main/assets.md#opentelemetry-bot

(several other OpenTelemetry repos are using this approach for automations: https://github.com/search?q=org%3Aopen-telemetry+OPENTELEMETRYBOT_GITHUB_TOKEN+language%3AYAML&type=code)

[CodeBlanch]

@trask I will try it out and report back.

[CodeBlanch]

@trask

So I got everything to work using opentelemetrybot: open-telemetry/opentelemetry-dotnet#5662

The big challenge I faced is trying to test everything via forks is very heavy lifting. I had to create my own org. I had to create my own bot account. I had to try and get everything as close as possible to the real things. I had to make the actual automation fully configurable so forks can use different accounts/users to support testing scenarios. I'll have to document this whole mess so others can work on it in the future.

The app approach above is much easier to work with IMO. For a fork you can create an app in your personal account and install it into your forks. You can give that app fine-grained access to whatever it needs to do (more so than the PAT). When you need a token you ask the app for one based on the specific thing you need to do in a workflow and when the workflow is done that token is revoked. No ephemeral PAT needed, no user accounts needed. I think it is worth looking at for the org as a better solution overall.

That being said, I'm fine living with this opentelemetrybot.

[svrnm]

@CodeBlanch you might be interested in this SIG/project proposal by @austinlparker:

• Project Infrastructure SIG #2096

My personal opinion on that matter is, that if we have an app, it should not be exclusive to a single repository and we should rather look into generalizing solutions across repositories.

[CodeBlanch]

we should rather look into generalizing solutions across repositories.

Definitely agree with this in general.

For this "use an app for granting permissions to automation" case though we may want to look closely at the implications. Let's say this app is installed in dotnet, dotnet-contrib, and java repos. The app will need permission to do everything required by automation for those repos. In dotnet we need to create branches, push commits, open PRs, create releases, and kick off actions. Let's say in java it needs to do package management. If we share an app, suddenly dotnet & dotnet-contrib can do package management. Also dotnet will be able to perform things in java's repo. Some isolation in this case I think is a good thing. Keeps the scope of permissions down and limits which repos can interact with each other. Just food for thought!

[trask]

moving from area/repo-maintenance to area/project-infra to see if there's a better way to do this in the future