CI and hex.publish

[Nate-Wilkins]

I'm really curious to see what the recommended workflow is for publishing to hex.pm using a CI server. I was trying to follow Tristan's blog post but it seems that it's a bit outdated.

In a nutshell I was trying to generate an unencrypted key that I could use for my CI pipeline. But issue #368 seems to derail that direction a bit implying a different workflow.

I've gone through all the hex docs regarding publishing but can't seem to find anything related to this.

I also took a look at credo and ecto to see what they were doing for automated releases but with no luck... 😞

Any pointers are greatly appreciated!

[ericmj]

There is no documentation about publishing from CI because we don't recommend it. Along with bumping the version in mix.exs, updating docs and changelogs, creating tags, etc., running mix hex.publish is not necessary to automate since it takes a few seconds to run. When publishing you also get useful information, warnings and errors that would be ignored of fail the build when automating on CI.

If you extend on what approaches you tried and how they failed we might be able to help out.

[Nate-Wilkins]

There is no documentation about publishing from CI because we don't recommend it.

Ah. That kindof sucks...

When publishing you also get useful information, warnings and errors that would be ignored of fail the build when automating on CI

Shouldn't maintainers choose whether they want to handle warnings coming from their pipeline? Just seems a bit inflexible. Frustrating because I've used tooling in other ecosystems that allow deployments to fail when there's a warning.

I know this might seem a bit head strong but I'm a huge fan of the elixir ecosystem and I want to help shed some light on why people might want this. (probably for reasons that were already considered 😨)

I tried a few different ways but in the end they all asked for the local password.

> mix deps.get && mix compile
  # authenticate.
> mix hex.user auth
  # manage keys.
> mix hex.key
  # hex build and publish.
> mix hex.build && mix hex.publish

What I was expecting was a workflow similar to this.

> mix deps.get && mix compile
  # env vars or 'hex.config' (preferably env - only persists for this instance).
> HEX_USERNAME="nate-wilkins"
> HEX_KEY="<<key>>"
  # strict to fail on warnings.
> mix hex.publish --strict

Sorry for the inconvenience if the elixir team is adamant about publishing manually then I can concede. Thanks for taking the time to help me out.

[ericmj]

Shouldn't maintainers choose whether they want to handle warnings coming from their pipeline? Just seems a bit inflexible. Frustrating because I've used tooling in other ecosystems that allow deployments to fail when there's a warning.

We do fail automatically on warnings. Usually CI tools are set up to publish or build when a tag is published. What do you when the deployment fails, do you ignore this tag, fix the issue, push a new tag and hope that CI passes this time?

What I was expecting was a workflow similar to this.

We could support something like this.

[Nate-Wilkins]

Warnings do fail! My bad, completely missed that.

If a deploy did fail (the assumption being from code at that tag) ideally I would delete the tag that caused the issue, put in a fix and re-tag.

Are there any big pitfalls into supporting something like this? I'm definitely willing to put some code together as a first take if you're interested.

Where the usage would like:

> HEX_USERNAME=nate-wilkins
> HEX_KEY=<<unencrypted-key>>
> mix hex.publish

[supersimple]

There is an existing pattern for pulling down deps form private organizations; mix hex.organization auth <ORGNAME> --key <KEYHERE>
It seems like a logical pattern to use for this task as well, eg. mix hex.publish auth <username> --key <KEYHERE>

alternately, there could be two steps mix hex.user auth <USERNAME> --key <KEYHERE> then mix hex.publish

[ericmj]

I would rather have it as an environment variable HEX_API_KEY so that we don't have to create new tasks or everywhere try to determine if the key is encrypted or not.

[ericmj]

Moved to #547.