Release v0.1.0-alpha

[MrAlias]

Blocking

• Allocate memory without launcher #40

[damemi]

With #40 merged, are we set to tag the release?

[MrAlias]

Do we want to setup a vanity URL for this package before we release it?

It currently has a package of github.com/open-telemetry/opentelemetry-go-instrumentation, but all other OTel Go projects use go.opentelemetry.io/.

[MrAlias]

Maybe go.opentelemetry.io/auto?

[MrAlias]

open-telemetry/opentelemetry-go-vanityurls#17

[damemi]

Vanity url looks really cool, I don't have a big preference on the name but definitely +1 to setting it up

[TylerHelmuth]

@MrAlias need to open this back up as the release workflow didn't pass. Looks like our dockerhub token isn't properly setup

[TylerHelmuth]

Followed up with the original ticket to create the secretes here: open-telemetry/community#1377

[TylerHelmuth]

@MrAlias I believe once the otel/autoinstrumentation-go repository exists we'll be able to re-run the failed job and get our images.

If we don't want to wait I believe we could update the release workflow to only push to ghcr.io, but we'd have to do a new tag to rerun the workflow.

[MrAlias]

If we don't want to wait I believe we could update the release workflow to only push to ghcr.io, but we'd have to do a new tag to rerun the workflow.

I'm okay waiting for the TC to try and create the repo.

[TylerHelmuth]

Think I should open a second ticket? Technically the closed ticket I linked didn't asked for the repository to be made, only for the secrets.

[MrAlias]

Think I should open a second ticket? Technically the closed ticket I linked didn't asked for the repository to be made, only for the secrets.

Yeah, that makes sense to me.

[TylerHelmuth]

New issue created: open-telemetry/community#1442

[MrAlias]

@TylerHelmuth: open-telemetry/community#1442 looks resolved, but the build is still failing:

https://github.com/open-telemetry/opentelemetry-go-instrumentation/actions/runs/4724518902/jobs/8406320441

[TylerHelmuth]

Ok I will keep investigating

[TylerHelmuth]

@MrAlias I tested this again with my own dockerhub credentials and it worked as expected :/

Can we check the DOCKER_USERNAME and DOCKER_PASSWORD secrets and ensure they are correct?

[TylerHelmuth]

I was able to reproduce the issue by generating a Read-only token and setting it for DOCKER_PASSWORD: https://github.com/TylerHelmuth/opentelemetry-go-instrumentation/actions/runs/4736205676/jobs/8407432789. So I'm back to thinking the issue is the token itself.

[MrAlias]

@MrAlias I tested this again with my own dockerhub credentials and it worked as expected :/

Can we check the DOCKER_USERNAME and DOCKER_PASSWORD secrets and ensure they are correct?

I don't have access to these settings. The TC would be the one with the access.

[TylerHelmuth]

@MrAlias the token has been recreated, can we retry the build?

[MrAlias]

https://github.com/open-telemetry/opentelemetry-go-instrumentation/actions/runs/4724518902/jobs/8410060528

[TylerHelmuth]

Pretty frustrating. I'm feeling more inclined to strip out the DockerHub stuff for now.

[TylerHelmuth]

Any chance the action we're rerunning is caching the old token and we'd need a new instance of the action to see the new token value?

[MrAlias]

Any chance the action we're rerunning is caching the old token and we'd need a new instance of the action to see the new token value?

I'm not an expert on the actions, but I vaguely remember those values updating every run.

I wonder if they are correctly being set and then interpreted in the environment.

[TylerHelmuth]

Unfortunately I can only test with my credentials and they work :/

[MrAlias]

I wonder if the second docker login is messing things up.

Also, having it use my alias as a username is almost certainly going to break things.

[TylerHelmuth]

I wonder if the second docker login is messing things up.

Maybe, but unlikely, since they are independent logins. The first instance of the docker/login-action action logs into DockerHub and the second instance logs into the ghcr.io registry. The DockerHub login uses the DOCKER_USERNAME and DOCKER_PASSWORD secrets and the ghcr.io login uses the GitHub context of the person who triggered the action.

For DockerHub login we'd be able to login even if the token doesn't have permission to push.

For the ghcr.io login I think we're following best practices, but since we haven't actually hit that step of the release yet we don't really know. Looking at the opentelemetry-demo repo we could use username: ${{ github.repository_owner }} instead.

[TylerHelmuth]

@puckpuck @austinlparker did either of you encounter any scope permission errors pushing to docker hub with the demo release?

[TylerHelmuth]

@MrAlias I spent some more time this morning investigating how different OTel repositories publish images and it looks like us and the operator are the only ones that use the docker/metadata-action and the operator only pushing to ghcr. I don't have any good theories right now as to why we are experiencing issues, especially since we are following GitHub best practices. My guesses:

• Something is still wrong with the token (seems very unlikely at this point since we have proof of a read/write token)
• We have issues pushing to otel/autoinstrumentation-go as the otelbot username based solely on this comment. The DockerHub otel account is a Community Organization tho so I don't see why using a username that does not equal the namespace should matter. This is a theory I can't test with my account since it only has 1 user.
• Something with specifying the tags in the the metadata action isn't playing nice with the docker/build-push-action action. The opentelemetry-demo repository is able to push to both repositories but they don't use the metadata action, opting instead to specify the tags directly in the docker/build-push-action action. The downside is that the demo images don't have all the labels we require.

With that information, how would you feel about removing the DockerHub stuff for now, creating an issue to add it back, and moving forward with only ghcr? This aligns us with the only other repository using metadata-action action, still provides an image in an appropriate place with the appropriate labels, and allows us to move forward with this release and any future releases.

[TylerHelmuth]

@open-telemetry/go-instrumentaiton-maintainers with the release workflow updated, and some other release-related work completing (#94, #98), how does everyone feel about doing a second release? This has the benefit of:

• Testing the new processes
• Providing an image which didn't happen with 0.1.0-alpha

[damemi]

Providing an image which didn't happen with 0.1.0-alpha

This is the key goal imo, +1 to another release

[MikeGoldsmith]

Yep, agree - even just to verify the release process successfully publishes an image would good. There are many in-flight PRs that improve the agent but another release when they're ready will be easier once we know the release process works as intended.

[robbkidd]

New Guy Input: release early, release often! Especially when it's -alpha. Exercise the evolving release pipeline and get changes out there to learn from closer-to-real-world consumption.

[pellared]

Providing an image which didn't happen with 0.1.0-alpha

We can also create 0.1.1-alpha so that we test the whole releasing processes.

[MrAlias]

We're resolving to "fail forward". Future releases will have a docker image.

See #131

[tigrannajaryan]

We may have found the reason why this didn't work, see the long thread: https://cloud-native.slack.com/archives/C033BJ8BASU/p1683062397439339

[tigrannajaryan]

When you have a moment try again.

[MrAlias]

New job: https://github.com/open-telemetry/opentelemetry-go-instrumentation/actions/runs/4724518902/jobs/8812701237

[tigrannajaryan]

Worked? https://hub.docker.com/repository/docker/otel/autoinstrumentation-go/general

[MrAlias]

Yay! Seems like it to me.

[TylerHelmuth]

Woo! Now we can add back the DockerHub release stuff.