PR or Tag based hex publishing

[tsloughter]

Opening this in hopes there is a kind soul interested in tackling this -- well, first assuming @bryannaegele supports this plan.

I'd like publishing to hex done through github actions. There are a couple ways to do this but I'm not sure the best. The issue is my initial idea is to base it on tags, so when a tag phoenix-1.1.1 is created then the version 1.1.1 is published of opentelemetry_phoenix. The problem is it'd be nice to have the application version be based on the tag if we aren't doing it off of a PR where it can be reviewed and this would be a pain for the Erlang apps.

Best would be if a PR could be opened to bump and release an application and it is done when that PR is merged. I don't know if that is even possible in Github Actions.

[tsloughter]

Hm, I guess with https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-your-pull_request-workflow-when-a-pull-request-merges and the labeler te second option could be done.

[bryannaegele]

I don't mind it but it gets super complicated and the flow would need to change source files and commit them to main.

We use https://github.com/marketplace/actions/release-drafter and releases at work but don't modify the app version. The mono-repo is going to make things complicated but it's theoretically possible.

For approach, releases probably make the most sense since we still need them to be manually released by the appropriate maintainer.

[tsloughter]

I wouldn't want it having to change source files and committing them to main. If the version is based on the tag then it just means the mix.exs has to parse it from the tag when building.

[bryannaegele]

Sure, but how is it going to do that? It has to be in the mix file afaik and you'd have to read from something, so maybe put it in an env var during the build? The other concern I have is you can overwrite a tag which is why I brought up releases. And we would lose the ability to publish a quick fix for the version without going through the PR process.

…

On Tue, Apr 25, 2023 at 12:08 PM Tristan Sloughter ***@***.***> wrote: I wouldn't want it having to change source files and committing them to main. If the version is based on the tag then it just means the mix.exs has to parse it from the tag when building. — Reply to this email directly, view it on GitHub <#167 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLXHVIBW5EPYMBWJUXRNXLXDAHJNANCNFSM6AAAAAAXKG4HSI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[btkostner]

Another option is to use release-please to create a release PR. This will also modify source files to adjust the version, but it will be done via a PR so it's easily reviewable. Plus it has built in support for mono repos, changelogs, and documentation updates.

While not a mono repo, here is an example elixir PR: stordco/data-streams-ex#13

[tsloughter]

No Erlang support :( but I guess it could be nice for Elixir packages in here

[btkostner]

There is a simple release type that just increments a version in the version file. Erlang could read that.

Otherwise, if this looks like a good solution, I can work upstream and add support.

[bryannaegele]

There is a simple release type that just increments a version in the version file. Erlang could read that.

Otherwise, if this looks like a good solution, I can work upstream and add support.

We don't want any actions/bots committing files, so I'm not sure that would work

#167 (comment)

[bryannaegele]

I'm working on this at work where we use release-drafter and finally found a legit monorepo setup.

https://github.com/guardrail-dev/guardrail/blob/master/.github/workflows/release-drafter.yml
https://github.com/guardrail-dev/guardrail/blob/master/.github/workflows/release.yml

Also found a way to secure who can trigger releases. It isn't pretty but would work. We're using github IDs rather than usernames though.

https://github.com/orgs/community/discussions/26008

[bryannaegele]

Alright. Got a job figured out at work to take a tag of project-semver and parse out the project and version. Those can then be used to figure out which job to run for a project and pass in the version as an arg. Since we can lock down who can create tags I don't really have a problem with having a manually triggered workflow only maintainers have access to that would write to a version file in the projects.

With the new rulesets we can get really granular.

Given a tag of opentelemetry-phoenix-v1.20.0-beta1 we'll get opentelemetry-phoenix as the project and v1.20.0-beta1 as the version.

    name: 'Extract project from tag'
    id: set-project-from-tag
    runs-on: ubuntu-20.04
    outputs:
      project: ${{ steps.set-project-from-tag.outputs.project }}
    steps:
      - run: |
          project="$(echo "$GITHUB_REF" | sed 's/\(^refs\/tags\/\)\([a-z-]*\)\(-v\)\(.*\)/\2/')"
          version="$(echo "$GITHUB_REF" | sed 's/\(^refs\/tags\/\)\([a-z-]*\)\(-v\)\(.*\)/v\4/')"
          echo "::group::Extract project and version"
          echo "extract project and version: ${GITHUB_REF}, ${project}, ${version}"
          echo "project=${project}" >> "$GITHUB_OUTPUT"
          echo "version=${version}" >> "$GITHUB_OUTPUT"
          echo "::endgroup::"

[tsloughter]

Great!

Maybe needs to be a path to the project tho? Like instrumentation/opentelemetry_phoenix-v1.20.0?