-
Notifications
You must be signed in to change notification settings - Fork 184
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI and hex.publish #532
Comments
There is no documentation about publishing from CI because we don't recommend it. Along with bumping the version in If you extend on what approaches you tried and how they failed we might be able to help out. |
Ah. That kindof sucks...
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. |
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?
We could support something like this. |
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 |
There is an existing pattern for pulling down deps form private organizations; alternately, there could be two steps |
I would rather have it as an environment variable |
Moved to #547. |
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!
The text was updated successfully, but these errors were encountered: