Add example to publish Hex packages

[yordis]

Hey there, it would be amazing if we could include some examples where we show how to publish packages to Hex.pm from CI, this way we can create releases in GitHub and automatically publish the package without having to do manual stuff.

Cheers,

[wojtekmach]

I think such example would be valuable but I believe it is out of the scope of this project. An example project that does that, a blog post, etc, seem like a better place, and we could link to that from this repo.

[yordis]

Could Hex.pm add it to the official docs?

I wouldn't support the idea of a blog post, from my perspective, I encourage people to read official documentation and use such documentation as the source of truth instead of Googling randomly, blog posts have a fixed-in-time value, where documentation is meant to evolve over time.

I would like either setup-beam to show some example, or the official Hex.pm website to show an example since when we direct people to read things, they can come across it.

Still, not sure what things are considered to decide what is "out of scope", I feel the task is such a common thing to do in your CI pipeline that leads me to disagree with you, and this package is about CI/CD stuff, so wouldn't be a better place to document things related to it, except closer to the tech, like Hex, or ExDoc, or Credo official docs.

[wojtekmach]

Just to be clear I was speaking just for myself, not the whole project, and it is definitely not up to me what is in the scope.

In my opinion automating releases is overrated. Heck, I even wrote https://hex.pm/packages/shipit and haven't used it for years. I can definitely imagine, and as a matter of fact am building one, projects where not automating releases is very likely going to be very impractical. But in my view that is more of an exception than a rule so we would have to agree to disagree how common it is of a thing to do.

[yordis]

On the flip side, dealing with forgetting to publish something, or forgetting to add a tag in Github in order to keep consistency or as a good practice; has been really annoying and hard to maintain in organizations like Ueberauth where they are many packages to keep track of.

The burden is catching up.

[wojtekmach]

That's what I am saying, if in your projects you need to automate, then automate away. And ideally write somewhere about it so others, including perhaps this project, could link to it.

I personally would not feel comfortable maintaining a guide that I don’t think most people need but would be fine linking to it.

Now, if you are trying to figure out how to actually automate it then it is a little bit different story. Are you?

[yordis]

I am trying to figure how to automate things.

I normally expect this repo to mention how to leverage the tool for different use cases, after all, the setup does matter depending on the CI/CD tool.

Also, it would be helpful if Hex mentions something about it as well since https://hex.pm/docs/publish doc is lacking good information about the topic.

[ericmj]

This action's purpose is to set up an environment in which you can use Erlang and/or Elixir. It doesn't have anything to do with Hex other than that for Elixir users it is installed because Hex is required to fetch some dependencies. For Erlang users Hex isn't installed so you wouldn't even be able to publish packages without installing additional things on top of this action.

Since this action isn't about Hex, I don't think we should document it, otherwise there would be so many other unrelated things to the action that should also be documented and need to be kept in sync with when the tools change.

I have added docs to https://hex.pm on how to automate publishing on CI: https://github.com/hexpm/hexpm/pull/1049.

All that being said I think care and consideration should be given before automating the publishing process since important information can be missed when you don't see the output from the tools you are using. Some projects or development processes need to automate it but I believe that most do not. If the problem is that mistakes can be made when the process is manual then I would say that you are introducing other possible mistakes when automating it. Instead I would recommend @wojtekmach's shipit tool that automates the process but it is still manual and run locally.

[yordis]

@ericmj thank you so much for the documentation update, that works as well!