TIL: How to Run Parallel Jobs on Gitlab CI (Different Stages)
If you are familiar with Gitlab CI you probably know that jobs in the same stages will run in parallel. However you can also run jobs in different stages at the same time. Let’s see our .gitlab-ci.yml looks like this:
stages: - test - deploy format: stage: test script: - task format lint: stage: test script: - task lint deploy:preview: stage: deploy only: - merge_request image: docker script: - task deploy So for my use case when a user creates a merge request, I want to run some tests against the code, such as linting and formatting.
In this post, I will show you how you can update your GitLab CI pipeline with the status of your Netlify deploys. As it is quite nice to have everything in one place if our CI pipeline passed or failed.
I have spoken about this in a previous article, how you might go about setting up merge request preview environments with Netlify.
This can be set up to also leave comments as shown above, and notify us if our website deployed successfully.
TIL: How to Setup Netlify, Gitlab And Sentry
I will show you in this post how you can integrate Gitlab, Netlify and Sentry. I may do a more detailed post in the future.
GitLab -> Sentry To connect Gitlab and Sentry follow this guide. Then add the repos you want to monitor in Sentry. In my case, it is the Bookmarkey GUI.
Netlify -> GitLab This integration is pretty simple just go through the normal Netlify setup process to add a new site.
TIL: How to Use DinD, localhost & Gitlab CI
In this post, I will go over how you can use docker-compose and Gitlab CI. In this example, we will be running playwright tests directly on the Gitlab runner. The tests will start a SvelteKit server also running on the Gitlab runner. The SvelteKit server will connect to PocketBase (backend) running in docker-compose.
So essentially we need a way for something running locally to connect to something running in docker in Gitlab CI (on a runner).
In this post, I will go over my new workflow for creating articles/posts that I now use with my new (Hugo) blog. Though I’m sure much of this will apply to other JAM stack sites as well.
Hugo Site Before carrying on, this post assumes you have an existing Hugo blog.
My Hugo blog setup looked something like this:
├── archetypes ├── config.yml ├── content ├── docker-compose.yml ├── Dockerfile ├── go.
TIL: You Can Schedule Posts on Your Hugo Blog using Netlify and Gitlab CI
This post in fact will be a scheduled post I’m writing it on the 20th of November but it will be published on the 23rd of November. Assuming we are using Netlify to deploy our website, what we will need to do is trigger a rebuild of our site every day using Gitlab CI. Since Hugo builds a static site to publish our content after a set date we will need to rebuild our site.
Shameless plug: This is related to a EuroPython 2022 talk I am giving, My Journey Using Docker as a Development Tool.
For most of my common dev tasks, I’ve started to rely on docker/docker compose to run commands locally. I have also started using vscode’s .devcontainers, to provide a consistent environment for all developers using a project.
The main reason for this is to avoid needing to install dependencies on my host machine.
Background This will be a slightly shorter article. In this article I will show you how I’ve managed to do some end-to-end testing with Gitlab CI services.
I’m building a browser-based multiplayer game called Banter Bus. Banter Bus consists of three main components,
gui: A SvelteKit based frontend the user will interact with to play the game core-api: A Socketio API written in Python management-api: A simple RESTful API written in Python (FastAPI) Now say I want to write some e2e Cypress tests, that will test all of these components interacting with each other.
In this blog post, we will go over how we can automatically test a Gatsby site end-to-end (e2e), using Cypress on Gitlab CI.
Introduction Gatsby Gatsby is a static site generator (SSG) built upon React. It allows us to create “blazing” fast websites. In this example, we will use a simple blog starter template available and add a Cypress test.
Cypress Fast, easy and reliable testing for anything that runs in a browser.
In this article, we will go over how you can manage your markdown blog posts from another git repository (repo). Separate to the git repository for your Gatsby site. This is the same process that I use to manage this repo.
So what this entails is the source code for my Gatsby site is in a repo called portfolio-site on Gitlab. Then I have another repo for all of my blog posts (in markdown) called articles.
In this article, we will go over how we can use the gitlab-auto-mr CLI script I wrote to help automate your Gitlab workflow. This is a very simple script you can use with Gitlab which will auto-create merge requests (MRs) every time you create a new branch on a project in Gitlab.
(Optional) Git Feature Branches Feel free to skip this section if you are already familar with feature branch, skip to the Gitlab Auto MR section
On a recent project, I was working on, I wanted to test my web service using docker-compose where I can run and kill Docker containers used by the application and see how my web application reacts to that. In this article, we will go over how you start docker containers using docker-compose from within Gitlab CI.
The diagram above is a visualisation of what we are trying to achieve. We want to spawn Docker containers using docker-compose from within our job.
Like most developers, we want to be able to automate as many and as much of processes as possible. Pushing Docker images to a registry is a task that can easily be automated. In this article, we will cover how you can use Gitlab CI to build and publish your Docker images, to the Gitlab registry. However, you can also very easily edit this to push your images to DockerHub as well.
In this article I will show you how you can deploy a Docz website on Gitlab pages, using .gitlab-ci.yml. Most of this article should be applicable to Github pages as well.
Docz Docz is a tool powered by Gatsby, it aims to make it easier to document your project. It uses a language called mdx which is like normal markdown with some extra features, i.e. md + jsx. The main advantage of using Docz is you can render components “live”, if you put them with the <playground> tags.
A bit of backstory when I first started developing React Native apps, I found there weren’t any good example of Gitlab CI files. So in this article, I will show you an example .gitlab-ci.yml file you can use with your React Native app. You can of course tweak and makes changes as required by your project.
CI/CD Before we dive straight into the CI file itself, let’s do a quicker refresher on some basic concepts.
In this article, we will talk about how you can use React Native with Firebase Cloud Functions. We will also go over how we can automate the process of updating the cloud functions using Gitlab CI.
Firebase is a cloud-based platform developed by Google to aid in the development of Web and Mobile applications. It is tightly coupled with the Google Cloud Platform (GCP), so much so that there are certain actions you can only do using the GCP GUI, such as increasing the RAM of your cloud function “containers”.
In this article, I will show you how can automate the publishing of your AAB/APK to the Google Play Console. We will be using the Gradle Play Publisher (GPP) plugin to do automate this process for us. Using this plugin we cannot only automate the publishing and release of our app, we can also update the release notes, store listing (including photos) all from GitLab CI.
Note: In this article I will assume that you are using Linux and React Native version >= 0.
In this article I will show how you can use the GitLab CI with React Native to create a binary which can be published to the Google Play Store.
Prerequisites Google Developers Account A working React Native Android project Keystore First, we have to generate a keystore which we will use to sign our APK. To do this run the commands below, follow all the instructions and keep the file safe.