DEV Community: Marc Riera

How to autocancel GitHub Actions workflows

Marc Riera — Thu, 05 Mar 2020 09:15:16 +0000

GitHub announced some months ago GitHub Actions, a system that allows you to run arbitrary code based on some given events happening around a given repository. People flocked to it, hoping it would allow them to run their test suites. This is particularly true for open-source projects, since GitHub gives out an unlimited amount of minutes to run actions for these kind of repos.

At Codegram we wanted to try it for some of our repos, but found some little issues that kind of made switching difficult. For example, GitHub Actions does not support autocanceling previous workflows.

Imagine this scenario:

I commit to a branch and push it to my repo
A CI build is triggered
Before the CI build is finished, I push again
Another CI build is triggered

What I'd like to happen is that the first CI build is stopped, since it's no longer necessary: it's become redundant, now that we have new changes.

Some CI services (CircleCI, for example) support autocancelling built on these kind of scenarios. Autocancelling is useful because it frees resources so that you can run newer, more up-to-date test suites, and it helps you save money (in case you're paying for those resources, of course).

Enter actions!

GitHub Actions has a concept that is a game changer, in my opinion: community actions. This means you can reuse actions made by other people, the whole community can benefit from them. And well, it took a while, but finally someone made it: an action to autocancel redundant builds. Here's how to use it:

on:
  push: []
jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
    - uses: rokroskar/workflow-run-cleanup-action@v0.2.2
      env:
        GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
    - uses: actions/checkout@v2.0.0
    ...

By running the action before checking out the repo we save a couple of seconds (it ain't much, but it's honest work) so we can cancel redundant workflows earlier. Beware, though: as its configured, it will run on any branch. We can limit it, though, to avoid autocancelling workflows on our master branch.

on:
  push: []
jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
    - uses: rokroskar/workflow-run-cleanup-action@v0.2.2
      env:
        GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
      if: "github.ref != 'refs/heads/master'"
    - uses: actions/checkout@v2.0.0
    ...

Note the if: part. I won't go into too much detail here, but we can conditionally run some steps based on the if: key. In this case, we're telling GitHub Actions to ignore this step if the current branch is master. You could add other branches, depending on your own workflow, but I hope you get the idea. Don't forget to check the repo for more info.

So, in any case, thanks Rok Roškar for your work on this action!

asdf: a version manager to rule them all

Marc Riera — Thu, 13 Feb 2020 15:11:11 +0000

When I started programming in Ruby, I had to install rvm (Ruby Version Manager) to use the correct Ruby version for each of the different projects I was in. After some time, I switched to rbenv (yes, that's another Ruby version manager) because rvm was too slow. but then a workmate appeared, saying chruby (you guessed it, yet another Ruby version manager) was even faster, so I switched again. All was good, flowers were blooming, rainbows appeared in the sky and butterflies... Butterflied? Butterflew? Well, whatever, butterflies did their thing.

Then NodeJS appeared and, of course, I had to install its own version manager. I went with nvm (Node Version Manager), but then I switched laptops and I tried n, a lighter version manager. I had some problems with it, so I finally went back to nvm. Butterflies started getting worried.

Then I started programming in Elixir. Guess my next step.

At this point, butterflies got sad and stopped butterflying.

This setup is not sustainable, for me. I need to keep remembering how to install new language versions, and when setting up a project I need to remember what files each of the version managers use to define what version this project uses. Oh, and I need to actually install all the needed version managers, and you'd probably want to set the version autodiscovery, so you always run the correct language version when changing projects...

"But Marc, you only need to install a new version once in a while, and you can set a project template that adds all the needed files", you might say. And you'd be right, it's not a big deal. But (of course there was a "but", otherwise this post would not make sense) this forces all devs in the project to install a version manager for each of the languages we need, and manually install the correct versions. This doesn't scale well.

Can we do better? Of course we can.

Enter asdf!

Managing the managers

asdf is a version manager version manager. No, that's not a typo! With asdf you install language version managers, and it offers a common syntax to install language versions:

asdf plugin-install elixir
asdf plugin-install ruby
asdf install elixir latest
asdf install ruby 2.7.0

See? I don't even need to know what version managers it uses, internally. And in your project you can setup the project language versions like this:

# .tool-versions
ruby 2.7.0
node 12.8
elixir 1.4.0

When cding to this project, asdf will automatically set the correct versions for you. And the best thing is that, if some workmate enters the project and they don't have the dependencies installed they can run this command:

asdf install

And asdf will install all the needed managers and versions! You can see the list of plugins here. Be sure to check the official docs for other useful commands!

Switching to asdf

Switching all your projects to asdf, though, might be a little tiring. And maybe not everyone in the team will want to use it (yet). In these cases, asdf lets you fallback to legacy version files, so that managers that support it fallback correctly (e.g. the .ruby-version file for rbenv):

# ~/.asdfrc
legacy_version_file = yes

Wrapping up

I hope you see the advantages of using asdf in your local machine. It's been a game changer for me, and since I installed it I haven't had any problem remembering how to install new language versions or how to change them.

Thanks for reading!

An i18n engine with translation rules?

Marc Riera — Tue, 01 Oct 2019 14:31:09 +0000

This is a long shot, but hopefully someone can help!

Some time ago I found an i18n engine that allowed you to define custom rules to improve the translation quality. Most i18n engines simply interpolate the argument to the translated string. This causes non-natural translations. An example is languages that use articles and apostrophes, like Catalan, French or Italian, or languages with cases, like German or Lithuanian.

This i18n engine let you define custom rules on how to generate those apostrophes depending on the argument that you're sending to the translated string.

Anyone knows something about it?

Thanks!

Using components in Phoenix templates

Marc Riera — Wed, 28 Aug 2019 09:40:47 +0000

Originally published at Codegram's blog.

As a mostly-Rails backend developer, I find Rails partials confusing. Don't get me wrong, they're useful. But they're hard to work with. In my experience, most of the times these partials will accept params, but there's no way to know what params they accept without looking at the partial content itself. And this makes me sad.

I usually write partials similar to frontend frameworks components. Minus the logic part, because I haven't found a way to have real components in Rails views. The most similar thing to what I'm looking for is Trailblazer's cells (which I really like!), but they're still not quite what I'd like.

We recently worked on project that had an admin dashboard built on Phoenix based on a Bootstrap template. This kind of templates usually add their own classes on top of Bootstrap, and those components require extra HTML structure so that everything looks as expected.

"Oh, it's the perfect use case for components!", I thought.

Componentizing Phoenix templates

Well, yes. This was the typical use case for partials. But Phoenix does not support partials explicitly as Rails does. Since Phoenix is very flexible, you can write a ComponentView and dump your shared layouts there:

<%= render ComponentView, "tabs.html" do %>
  <%= render ComponentView, "tab.html", name: "All Products" %>
  <%= render ComponentView, "tab.html", name: "Featured" %>
<% end %>

The tabs.html file contains the wrapper layout for a tabs element, and the tab.html contains the layout for a single tab.

You can give a little twist to that idea, and simplify it to this:

<%= component "tabs.html" do %>
  <%= component "tab.html", name: "All Products" %>
  <%= component "tab.html", name: "Featured" %>
<% end %>

Now we have a similar feature as Rails has, but since we're using a single view for all components, all component-related helpers would be written there. All together.

Multiple views

Exploring alternative implementations of components I found Kim Lindholm's Phoenix component Folders repo. If you follow the suggestions in the README file, you'll be able to have multiple component views, so that helper methods can be isolated. This allows us to write something like this:

# lib/my_app_web/components/tabs/tabs_view.ex
defmodule MyAppWeb.Components.TabsView do
  alias MyAppWeb.Components.ComponentHelpers
  use MyAppWeb, {:view, ComponentHelpers.view_opts(:tabs)}
end

# in your template:
<%= component :tabs do %>
  <%= component :tabs, :tab, name: "All Products" %>
  <%= component :tabs, :tab, name: "Featured" %>
<% end %>

This got us the same functionality Rails has... with the same problems: what params does a component accept?

Using helper methods to know the needed params

The fact that I couldn't see, at a glance, the params needed to build a component bugged me. I could leave it as it was, really. After all, I had been developing like that with Rails for a long time. But Elixir has a powerful toolkit to generate static docs from the documentation in the code, and I wanted to use that.

Finally, I created helper methods. Some of them wrapped the calls to the component methods, others created template syntax directly:

def icon(%{icon_name: name, icon_color: color}) do
  content_tag :span, class: "icon-holder" do
    ComponentHelpers.component(:icon, color: color, icon: name)
  end
end

You could even use the ~E sigil to simplify the needed code:

def icon(%{icon_name: name, icon_color: color}) do
  ~E"""
  <span class="icon-holder">
    #{ComponentHelpers.component(:icon, color: color, icon: name)}
  </span>
  """
end

With that I could write static docs, and my IDE can catch it and give me hints about the needed parameters.

Conclusion

This is quite a new approach for me and I probably need more opportunities to see how it matures, so I don't have a final decision on how to write components in Phoenix. I like the final approach using helper methods wrapping my components to get nice documentation, though.

What are your thoughts on this approach? Have you used something similar? Is there something I missed?