test(oban): fixes failing tests

[grzuy]

As stated in #436 (comment) there are quite a bit of pending needed improvements for opentelemetry_oban.

Trying to help with that in going in small, easy to review steps.

First would be to make opentelemetry_oban tests green I guess, so that follow PRs can be expected to continue having green checks.

Just that here.

[grzuy]

Not sure why "Opentelemetry Oban" job was skipped...

[grzuy]

maybe because it was skipped before the labeler was able to label the PR?

[grzuy]

I can't hit "Re-run" button for the checks. Maybe someone else can 🙏

[tsloughter]

I don't know why they aren't running.. the labels look right https://github.com/open-telemetry/opentelemetry-erlang-contrib/blob/main/.github/workflows/elixir.yml#L354

[grzuy]

I don't know why they aren't running.. the labels look right https://github.com/open-telemetry/opentelemetry-erlang-contrib/blob/main/.github/workflows/elixir.yml#L354

It seems the if condition is working when the target branch is from this upstream repo (open-telemetry), but not for pull requests from forked repos?

Upstream repo PRs:

• chore(deps): update dependency finch to ~> 0.20 #547 did run opentelemetry_finch tests
• chore(deps): update dependency opentelemetry_bandit to ~> 0.3.0 #548 did run opentelemetry_bandit tests

Forked repo PRs:

• feat(phoenix): trace LiveView render #529 did NOT run opentelemetry_phoenix tests
• Widen allowed semantic_conventions for tesla and oban #514 did NOT run opentelemetry_oban tests
• Update semantic conventions in opentelemetry_oban #528 DID run opentelemetry_oban tests (not sure why in this case - it seems the 2nd commit is after github was able to label the PR, maybe worked because of that?)

[grzuy]

Nudging GitHub with a new commit

$ git commit --allow-empty -m "empty commit 1"
$ git push

did the trick ✔️

I guess it made GitHub re-evaluate those if conditions with the labels present?
Not sure.

[tsloughter]

Weird... I reran the test manually after you commented. That is frustrating if rerunning them doesn't reevaluate the rules, that means there is no way but to push new commits...

[grzuy]

I don't know why they aren't running.. the labels look right https://github.com/open-telemetry/opentelemetry-erlang-contrib/blob/main/.github/workflows/elixir.yml#L354

It seems the if condition is working when the target branch is from this upstream repo (open-telemetry), but not for pull requests from forked repos?

Upstream repo PRs:

* [chore(deps): update dependency finch to ~> 0.20 #547](https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/547) did run opentelemetry_finch tests

* [chore(deps): update dependency opentelemetry_bandit to ~> 0.3.0 #548](https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/548) did run opentelemetry_bandit tests

Forked repo PRs:

* [feat(phoenix): trace LiveView `render` #529](https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/529) did NOT run opentelemetry_phoenix tests

* [Widen allowed semantic_conventions for tesla and oban #514](https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/514) did NOT run opentelemetry_oban tests

* [Update semantic conventions in opentelemetry_oban #528](https://github.com/open-telemetry/opentelemetry-erlang-contrib/pull/528) DID run opentelemetry_oban tests (not sure why in this case - it seems the 2nd commit is after github was able to label the PR, maybe worked because of that?)

Scartch all my speculation here about upstream vs fork repo.

It seems it is because of the chronological order of the commit vs the bot adding the labels.

In the case of renovate PRs I linked to it worked because the last commit is after the labels were set.

[grzuy]

Weird... I reran the test manually after you commented. That is frustrating if rerunning them doesn't reevaluate the rules, that means there is no way but to push new commits...

Apparently a known limitation of reading labels from the github.event that triggered the first attempt: https://github.com/orgs/community/discussions/39062.
Bummer.

[grzuy]

As far as this oban test fix goes, it's ready and apparently with green tests.

The label issue broader issue affecting any PR for any instrumentation library I guess.

[tsloughter]

Thanks! And will merge this.

[grzuy]

That is frustrating if rerunning them doesn't reevaluate the rules, that means there is no way but to push new commits...

I think the problem is that the workflow event we are "re-running" is the pull_request.opened event.
The problem seems to be that the pull_request.labeled event, which is already listed in .github/workflows/elixir.yml event is NOT triggering.

It seems the cause could be the .config/workflows/labeler.yml using the GITHUB_TOKEN

opentelemetry-erlang-contrib/.github/workflows/labeler.yml

Line 15 in 5f0b11e

repo-token: "${{ secrets.GITHUB_TOKEN }}"

to create the labels on the pull requests is not triggering the pull_request.labeled event in .github/workflows/elixir.yml

opentelemetry-erlang-contrib/.github/workflows/elixir.yml

Line 7 in 5f0b11e

types: [opened, reopened, synchronize, labeled]

.

It needs to be a github app token or a personal access token apparently.

sources:

• https://github.com/orgs/community/discussions/49997
• https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow#triggering-a-workflow-from-a-workflow

[grzuy]

Thanks! And will merge this.

Thanks.

I think an approval still pending for auto-merge to kick in.