Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library (https://hexdocs.pm/distillery/home.html).
Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and try to fix things up. But when shit hits the fan, do you want to discover the hidden dependencies (e.g. bash vs POSIX sh)? I wouldn't want to bet on a single point of failure like that.
And the big problem for Elixir is that you don't see that level of mess or siloed knowledge with other languages. Say what you will about something like Capistrano, but it's an order of magnitude easier to dig into and support because it's not mashing together a variety of languages (erlang, bash, elixir). Some languages like anything JVM based (that compile down to JARs), Rust, and Go compile down into single artifacts quite easily. Others like Ruby and Python can be moved around with standard system tools easily enough.
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them.
The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with everything else in Elixir, we do our best to keep the Erlang <-> Elixir interface pretty clean. You should expect the same level of quality and polish as the remaining of the Elixir tooling.
I am not sure about this point though:
> Others like Ruby and Python can be moved around with standard system tools easily enough.
If you are not using releases, and simply Mix, is Elixir any harder to move around then Ruby and Python? From my understanding, using Mix to run Elixir in prod is a similar experience that both Ruby and Python would provide.
If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them.
I've articulated my experience in my previous reply to you, but I'll pose this response: that it's taken so long for Elixir to come up with a manageable deployment story makes it seem like deployments are an afterthought with Elixir. If things are better now that's great, but as an ops guy by trade I think that deployments are one of the most important user stories out there.
I suspect one of the reasons people are gravitating towards Rust for things it's not particularly well suited for (like web apps with a ton of business logic) is that the Rust team focuses on important user stories like:
These are things that Elixir and Phoenix aren't focused on. For example I still get the occasional email from github about the poor souls trying to use distillery on FreeBSD so I don't buy that things have improved that much.
The Elixir tooling is fantastic, not sure where you pulled that one out from. IDE's are unnecessary cruft to the point that I'd call it a language-design smell if you really felt compelled to use one; VSCode is great. Deployments are trivial if you use Gigalixir (which has a free tier) and will be easier in the general case going forward.
I think doing it like that is a neat idea. Perhaps there could be an "advanced" page which is as you describe and the current method could be the "simple" version?
I think there are several avenues that could be explored with this. I wanted to stay away from explicitly checking the code initially, as there are other tools aimed at that specific task, however there is no reason something like this couldn't be added into GitCop at a later date.
I had the idea of checking that the user exists in a list of users by specifying a JSON list of users. This means that it could be used to check if a CLA has been signed, but there are other applications too. Does this seem like a reasonable way to do it?
I like the idea of ensuring a test has been added, not sure how to tackle it, but it is certainly worth keeping in mind.
I think what I was aiming at is integration with other tools, rather than adding those checks directly into GitCop (as you said, there are already services that check code, validate CLA etc).
Or maybe provide me with a Travis-like sandbox where I can run my checks with whatever linter/validator/custom code I want and report the results back?
Hi, thanks for the feedback, it would be great to be used by a project like Foreman!
Currently the string for the format only allows the 3 defined variables, type, scope and description. I have been using this style at https://github.com/Gazler/changex/commits/master to give you an idea of how it works.
I was concerned that the format string might be a little weird to get from the help. I will try and clear this up a bit.
I have attempted to build the string that you requested, currently an or separator is not supported, but I can take a look at adding it in.
Here are the format strings that I think match your use case. Using a colon as a separator:
Interesting, that makes sense. I'll check if the rest of the team would be ok with forcing commits to use colon as a separator until that feature is added. :)
Still, what does %{scope} actually catch? Anything that's not %{type}, %{description} or an explicit character?
So the match is exact between the non %{..} characters. The idea for scope is the context of the commit, in my libraries I use the name of the class as the scope.
For example with the default format string:
test string: "fix(User): ensure email address is required"
format: "%{type}(%{scope}): %{description}"
[type: "fix", scope: "User", description: "ensure email address is required"]
So any literal characters are matched exactly and anything inside the capturing %{...} is assigned to that variable.
This does fall over in the following case:
"fix():(User): ensure email address is required"
"%{type}(%{scope}): %{description}"
[type: "fix", scope: "):(User", description: "ensure email address is required"]
It is certainly a candidate for improvement in the future.
I think that's a key point, the earlier you can catch the problem the less frustrating for both sides. There is https://www.npmjs.org/package/commitplease for commit hooks but it's still handy to have something audit pull requests.
The master version of Elixir also has support for releases https://hexdocs.pm/mix/master/Mix.Tasks.Release.html