At Localazy we aim to provide you with as many flexible tools as possible to build your own CI/CD workflows. When used properly, these tools can help you to fully automate the management of your localization resources from your code to Localazy and back. The biggest advantages? More time for you to focus on things that actually matter and fewer faulty moves at the same time.

🏷️ Use Release tags Localazy's GitHub action 🔗

One of our most favorite ways of automating workflows is GitHub actions. For a general introduction, you can read our dive-in article here. In this article, you're going to learn about our latest addition to Localazy's download GH action - the ability to use Release tags.

Release tags work pretty much like tags on Github, Gitlab, or Docker. They allow you to mark the state of your Localazy app, preserving the translations and translation progress at the given time. This is super useful, for instance, when you use different branches for production, testing, and development.

You can preserve translations for production for as long as you are preparing a new release and only once you publish it, you start using the latest translations as well.

You can read more about Release tags in the documentation.

👀 Show me 🔗

Alright, I'll show you. 

### .github/workflows/localazy.yaml

name: Localazy
on: 
  push:
    branches: [ main, develop ]
jobs:
  release-tag:
    name: Download release tag
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: localazy/download@v1
        with:
          release_tag: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}
      - uses: actions/upload-artifact@v2
        with:
          name: locales
          path: src/locales/*

In the example above, in a file .github/workflows/localazy.yaml, we're defining a GH with a single job release-tag.  In it, localazy/download action is invoked with a single argument - release_tag. As you can see, I'm using a neat trick that checks whether we are running this action on main branch or not - if yes, we'll download localization resources that are tagged production, otherwise we'll download everything under staging.

This configuration presumes you have access to release tags through a professional plan, and production and staging tags exist in your app.

In order to quickly check what was downloaded, I also added action for uploading gathered artifacts. That way you can check the result of the download action right in Github's interface (in the Actions tab). Just make sure you properly define the path to gather all your localization files (src/locales/* would gather everything in the src/locales folder). And that's it.

✔️ Closing Words 🔗

This was a quick introduction to how you can utilize the power of release tags with GH actions. As you can see, it's pointless doing any of that manually when you can automate it 😊. Check out the sample repo for reference. Happy coding!