Indeed! Would you consider a PR where I extract the leaves/sprouts and git pushing functionality into a separate package, so that I could then build a mix task for my purposes?
JH -- John Hamelink Sent with Airmail On 11 October 2016 at 16:38:30, Aleksei Matiushkin ( [email protected]) wrote: Hey John, Allen is right, it’s about publishing to `hex`, but you might want to adopt version suggestion code (https://hexdocs.pm/issuer/ Issuer.Utils.html#sprouts/1) -- AM On Tue, Oct 11, 2016 at 5:33 PM, Allen Madsen <[email protected]> wrote: > Hey John, Aleksei's package is for automating package releases to hex > rather than application releases for deployment. > Allen Madsen > http://www.allenmadsen.com > > > On Tue, Oct 11, 2016 at 11:20 AM, John Hamelink <[email protected]> wrote: > > I'd like to put forward my usecase for this sort of functionality. > > > > At my company, we build debian packages from our releases using my > module - > > ExrmDeb - with Jenkins. When a git push is made to master, this triggers > a > > build which is then deployed onto our staging environment. We've > currently > > implemented the auto-versioning functionality in bash scripts, which I > don't > > particularly like as they are not as smart and fully featured as they > > could/should be. > > > > One of the most annoying edge-cases is when 2 commits which would > trigger a > > package build happen in quick succession, and one job doesn't know about > the > > other so they both try to mark themselves as the same version and one of > > them fails. > > > > When we're in staging, we don't care about semver - we manually review > the > > changes between staging and production and make sure our production > versions > > conform to semver as part of the production release process. > > > > Aleksei, I'll give your package a go :) > > > > JH > > > > On Monday, October 10, 2016 at 12:26:15 PM UTC+1, Aleksei Matiushkin > wrote: > >> > >> Hi again, > >> > >> I have the functionality discussed in this topic implemented. > >> > >> https://github.com/am-kantox/issuer > >> > >> Please note, this is a [fully functional] prove of concept. It adds `mix > >> issuer` task to `mix`. This task does the following steps: > >> > >> — runs `mix test` > >> — loads the list of existing tags from remote repo and gives the lists > of > >> suggestions (https://hexdocs.pm/issuer/Issuer.Utils.html#sprouts/1) > for what > >> version we are to bump > >> — updates the version in both `config/VERSION` and `README.md` > >> — git commit -am ':paperclip: Bump version #{version}.' && git push && > git > >> tag version && git push --tags > >> — hex publish > >> > >> The above is done in the safest manner I could imagine. I am open to > >> suggestions, ideas, swearing, cursing, profanity. I have already > switched to > >> using `issuer` for publishing in a) `issuer` itself and another package > I am > >> maintaining. > >> > >> Thanks for your attention. > >> > >> On Friday, September 30, 2016 at 4:59:00 PM UTC+2, José Valim wrote: > >>> > >>> Even with moving the version to a file, it still feels like it is more > >>> trouble than it is worth. Not all version bumps are the same. I may > want to: > >>> > >>> 1. Bump major > >>> 2. Bump minor > >>> 3. Bump tiny > >>> 4. Bump to any of the above and add a -dev suffix > >>> 5. Bump from -dev to -rc > >>> 6. Bump from -rc.x to -rc.x+1 > >>> > >>> And there is one very easy way to do this: open up the file where the > >>> version is written, be it mix.exs or a separate file, and just change > the > >>> version. Of the whole release process, bumping the version is the > *hardest* > >>> part to automate because one API that considers all cases above will > be much > >>> harder to use than doing the change yourself. > >>> > >>> Here are all saner and simpler to use alternatives: > >>> > >>> 1. Pass the version explicitly. Pros: it is explicit and you can check > >>> the new version is more recent than the current one. Cons: you still > need to > >>> parse the file where the version is listed. > >>> > >>> mix publish 0.5.0 > >>> > >>> > >>> 2. Assume the version has already been changed and committed. Pros: IMO > >>> that's the sanest approach because there are other things I need to do > when > >>> publishing a package besides bumping the version, such as versioning > the > >>> CHANGELOG and adding dates. You could still have a "mix publish" > command > >>> that would read the version and do the rest of the work: > >>> > >>> > >>> git tag v0.5.0 > >>> > >>> git push --tags > >>> > >>> mix hex.publish > >>> > >>> > >>> Even though, don't expect such to be added to Elixir. It does too > little > >>> and is too opinionated. > >>> > >>> José Valim > >>> www.plataformatec.com.br > >>> Skype: jv.ptec > >>> Founder and Director of R&D > >>> > > -- > > You received this message because you are subscribed to the Google Groups > > "elixir-lang-core" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/elixir-lang-core/ > 06c77da7-3268-4bd2-bcb3-9abfa97d4890%40googlegroups.com. > > > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elixir-lang-core/MMB3ru8Rcxc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/CAK-y3Cv%3D2S0UediwXKHCqcYcFkXx-% > 2B-s8pPhnDj0xeCvqc%2BRTA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. > -- *Aleksei* -- You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/MMB3ru8Rcxc/unsubscribe. To unsubscribe from this group and all its topics, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGF5_6fqADOn-a2R%2BCvusag_%2BHM5xq8X1atUtad5SRkdX7_rhQ%40mail.gmail.com <https://groups.google.com/d/msgid/elixir-lang-core/CAGF5_6fqADOn-a2R%2BCvusag_%2BHM5xq8X1atUtad5SRkdX7_rhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAFKGwZy45YoG9dzJL6EUE9StsuL%3DES1EaLCVfCu%2BNGWG%2BiTR0w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
