# CI/CD Pipeline Published articles for CI/CD Pipeline. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Automated Worker Versioning with GitHub Actions DevFeed: [Automated Worker Versioning with GitHub Actions]() Original publisher: [Read original article]() Author: Adam Quan Published: 2026-09-09T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [GitHub Actions](), [CI/CD](), [Deployment](), [Orchestration]() Tags: [automation](), [ci-cd](), [ci-cd-pipeline](), [deployment](), [github-actions](), [how-to](), [temporal-voices]() ### AI overview This tutorial explains how to automate Temporal Worker Versioning in a CI/CD pipeline with GitHub Actions and Worker Controller. It covers deterministic Workflow code changes, deployment versions, traffic ramping, pinned and auto-upgrade Workflows, safer rollouts, and rollbacks. ### Source excerpt Learn how to automate Temporal Worker Versioning in CI/CD with GitHub Actions and Worker Controller for safer rollouts, traffic ramping, and rollbacks. ## Publishing Playwright HTML reports on GitLab Pages DevFeed: [Publishing Playwright HTML reports on GitLab Pages]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-29T23:56:10Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [GitLab](), [Playwright](), [CI/CD](), [CI/CD Pipeline](), [Publishing]() Tags: [bun-create-playwright](), [ci-cd](), [ci-cd-pipeline](), [github-pages](), [gitlab](), [gitlab-ci](), [playwright]() ### AI overview This tutorial explains how to add a deploy stage to a GitLab CI/CD pipeline for a Bun-based Playwright project. The stage publishes generated Playwright HTML reports, including screenshots and videos, to GitLab Pages so they can be viewed online. ### Source excerpt We've added a lot to our demo project, bun--create-playwright. We've explored setting up a Playwright framework using bun, a new package manager bundled into Claude Code. We've added typechecking, and formatting and linting. We've set up a CI/ CD pipeline for our tests using GitLab, one with three stages: Quality: We check that the formatting, linting and typechecking is correct for any changes we attempt to push to the code base. Test: We run the smoke and then the regression tests to make sure that everything still works. Report: We bundle an archive of the Playwright generated HTML report, with screenshots and videos if things fail. For this post, we will add a new stage to this GitLab pipeline: Deploy: Where we will deploy the HTML report to GitLab Pages, so we can view it online. What is GitLab Pages? GitLab Pages is a built-in feature of GitLab that allows you to publish static websites directly from a repository in GitLab. Similar to GitHub Pages, it is commonly used to host project documentation, personal blogs, portfolios, or corporate landing pages for free. From the GitLab Docs / Pages: "To use GitLab Pages, you must create a project in GitLab to upload your website's files to. These projects can be either public, internal, or private. "By default, GitLab deploys your website from a specific folder called public in your repository. You can also set a custom folder to be deployed with Pages. When you create a new project in GitLab, a repository becomes available automatically. "To deploy your site, GitLab uses its built-in tool called GitLab CI/CD to build your site and publish it to the GitLab Pages server. The sequence of scripts that GitLab CI/CD runs to accomplish this task is created from a file named .gitlab-ci.yml, which you can create and modify. A user-defined job with pages: true property in the configuration file makes GitLab aware that you're deploying a GitLab Pages website. "You can either use the GitLab default domain for GitLab Pages websit ## Examining the artifacts job of a Playwright GitLab CI / CD pipeline DevFeed: [Examining the artifacts job of a Playwright GitLab CI / CD pipeline]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-29T23:19:22Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [Playwright](), [GitLab](), [CI/CD Pipeline](), [CI/CD](), [test]() Tags: [bun-create-playwright](), [ci-cd](), [ci-cd-pipeline](), [gitlab](), [playwright](), [screenshots](), [test](), [trace](), [videos]() ### AI overview This tutorial examines how a Playwright GitLab CI/CD pipeline stores and exposes test artifacts. It explains the playwright-report, test-results, and reports/junit folders and describes generated HTML and JUnit reports, screenshots, videos, and trace reports. ### Source excerpt You may have noticed that in the GitLab CI / CD Pipeline for our Playwright project, in the .gitlab-ci.yml file, after our scripts has run, in the Test stage, there is a subsection called "artifacts" with certain paths to something called "playwright-report", "test-results", and "reports". The Playwright -> Artifacts -> Reports stage playwright: extends: .bun_playwright stage: test timeout: 30 minutes ... ... artifacts: when: always paths: - playwright-report/ - test-results/ - reports/ reports: junit: reports/junit/results.xml expire_in: 30 days https://gitlab.com/tjmaher/bun-create-playwright/-/blob/main/.gitlab-ci.yml Every time Playwright tests run, it generates proof of the test execution: screenshots capturing the state of the UI when a test failed, video recordings of an entire browser session, HTML and JUnit XML test reports, trace reports showing action logs, network requests. These artifacts, when the tests run locally, are placed by the Playwright Test runner in generated folders, playwright-report and test-results, along with a folder called reports/junit. With this post, we will be examining how this artifacts stage of the GitLab CI/ CD pipeline produces downloadable artifacts we can examine. Playwright-Report: A Playwright Test folderThe Playwright Test runner creates a folder called "playwright-report", if it doesn't already exist, and an HTML file called index.html documenting the completed test run. From Playwright.dev / Test Reporters: "Playwright Test comes with a few built-in reporters for different needs and ability to provide custom reporters. [...] All built-in reporters show detailed information about failures, and mostly differ in verbosity for successful runs. [...] HTML reporter produces a self-contained folder that contains report for the test run that can be served as a web page". The HTML Report is the one that automatically opens after you run your tests locally, or if you are using the node package manager: npx playwright show-report ## Setting up a CI/ CD pipeline with GitLab: Quality, Test and Report DevFeed: [Setting up a CI/ CD pipeline with GitLab: Quality, Test and Report]() Original publisher: [Read original article]() Author: T.J. Maher (noreply@blogger.com) Published: 2026-08-25T02:28:52Z Content type: tutorial Language: en Sources: [T.J. Maher]() Topics: [CI/CD Pipeline](), [GitLab](), [Testing](), [Playwright](), [pull-requests](), [TypeScript]() Tags: [bun-create-playwright](), [ci-cd](), [ci-cd-pipeline](), [code-reviews](), [gitlab](), [playwright](), [test](), [testing](), [typescript](), [workflows]() ### AI overview A tutorial on setting up a three-stage GitLab CI/CD pipeline for merge requests. The pipeline runs code-quality checks, smoke and regression tests, and produces a downloadable report, with stages executed sequentially and jobs within each stage running in parallel. ### Source excerpt So far, we have reviewed how to review code with ES Lint + Prettier and Typecheck, how to set up and run smoke tests, how to run all Playwright + TypeScript tests, and reviewed the HTML report of results. In this post, we are going to set up a three stage GitLab CI/ CD pipeline that will run against every merge request: Quality (lint, typecheck, prettier) --> Test ( smoke + regression ) --> Report ( Downloadable ) I haven't used GitLab since when I worked at ThreatStack back in 2020. ( See my blog entry Getting to Know GitLab and How They Test the UI ) GitLab reads .gitlab-ci.yml from the repository root and turns it into a pipeline, a set of jobs, grouped into stages, running whenever you push a change to a repository. Stages run one after another, and jobs within a stage run in parallel. If one stage fails, the stages after it are skipped. This begs the question: What is GitLab? What is CI/ CD? Or a pipeline? Or a merge request? What is GitLab? GitLab began in 2011 as a side project by Ukrainian programmer Dmytro Zaporozhets, built to help developers work together on code more easily. Over time, it grew into a large open-source DevOps platform. More than just storing code, it handles code reviews, CI/CD (continuous integration and continuous delivery), and package registries. A company called GitLab Inc. was eventually created to turn the project into a commercial product. What makes GitLab different from tools that only host Git repositories (like a basic Git server) is that it bundles the entire software delivery process into one application. This includes: Merge requests - GitLab's term for proposing and reviewing code changes before they're merged into the main codebase (similar to a "pull request" in GitHub) Issue tracking - a built-in system for logging bugs, tasks, and feature requests Pipelines - automated workflows that build, test, and deploy code whenever changes are pushed So instead of stitching together separate tools for version control, testing, an ## Software Delivery Platform: Key Features & How to Evaluate DevFeed: [Software Delivery Platform: Key Features & How to Evaluate]() Original publisher: [Read original article]() Author: Eric Minick Published: 2026-08-11T00:00:00Z Content type: article Language: en Sources: [Harness Blog]() Topics: [Software](), [CI/CD](), [Continuous Delivery (CD)](), [Continuous integration]() Tags: [audit](), [automation](), [blog](), [ci-cd](), [ci-cd-pipeline](), [governance](), [how-to](), [progressive-delivery](), [rollback](), [scalability](), [security](), [software-delivery](), [visibility]() ### AI overview This article explains how a software delivery platform differs from a standalone CI/CD tool. It describes a platform as an integrated system covering the full after-code lifecycle, including continuous integration, continuous delivery, security, governance, insights, coordination, and rollback, then outlines criteria for evaluating vendors. ### Source excerpt A software delivery platform isn't just a CI/CD tool. Get the must-have feature checklist and the demo questions to use when evaluating vendors. | Blog ## Blue Green and Canary Deployments Explained DevFeed: [Blue Green and Canary Deployments Explained]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-09T16:30:08Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [Deployment](), [Software](), [Database]() Tags: [argo-rollouts](), [automation](), [blue-green-and-canary-deployments](), [ci-cd](), [ci-cd-pipeline](), [cloud](), [database](), [deployment](), [deployment-strategies](), [devops](), [dora-change-failure-rate](), [expand-and-contract-migration](), [feature-flags](), [guide](), [kubernetes](), [progressive-delivery](), [release-management](), [rollback](), [rolling-update](), [schema](), [sre](), [traffic-splitting](), [zero-downtime-deployment]() ### AI overview This guide explains blue-green and canary deployment strategies for replacing running software versions. It emphasizes that effective rollback depends on detecting problems with reliable metrics and that database schema changes can limit reversibility. ### Source excerpt Both strategies buy you the same thing, which is a cheap way to be wrong. The mechanism is the easy part, and the two hard parts are noticing you are wrong and dealing with the database. ## A Story of Delayed AWS Pipelines DevFeed: [A Story of Delayed AWS Pipelines]() Original publisher: [Read original article]() Author: Vladimir Romashov Published: 2026-05-08T14:23:22Z Content type: article Language: en Sources: [Booking.com Development - Medium]() Topics: [Amazon Web Services](), [Terraform](), [AWS Organizations](), [Infrastructure as code](), [CI/CD](), [Security]() Tags: [aws](), [aws-organizations](), [booking](), [ci-cd](), [ci-cd-pipeline](), [infrastructure-as-code](), [pii](), [terraform]() ### AI overview The article investigates delays in Terraform CI/CD pipelines caused by repeated use of the aws_organizations_organization data source and interactions with the AWS Organizations API. Testing found that roughly 1 in 10 Terraform pipelines were affected, with delays ranging from 1 to 15 minutes, while comparable CDK pipelines were not delayed. ### Source excerpt How a seemingly simple AWS API call can silently slow down your CI/CD pipelines Review/co-researcher: Gonzalo Ulla The Mystery It started with a line in one of our team's CI/CD logs that nobody expected: module.project.module.user_buckets.module.s3_bucket.data.aws_organizations_organization.current: Still reading... [15m10s elapsed] 15 minutes and 10 seconds -- just to read organization data. A value that should return in milliseconds was holding up entire pipelines. After digging deeper, we discovered this wasn't a one-off issue. During testing, roughly 1 in 10 pipelines containing Terraform were affected, with delays ranging from 1 to 15 minutes each. At Booking.com, we deploy and manage our AWS infrastructure using two primary Infrastructure as Code (IaC) technologies: Terraform and AWS Cloud Development Kit (CDK). To standardize and enforce our compliance and security controls, we maintain a set of internal Terraform and CDK modules to provision resources that handle personally identifiable information (PII). Interestingly, only Terraform pipelines were affected by this issue -- CDK ones running in the same accounts and against the same AWS Organization were completed without any delays. [spoiler alert/] CDK uses CloudFormation under the hood, which doesn't make additional Organizations API calls directly. [/spoiler alert]. This ruled out a general AWS-side outage or account-level throttling and pointed us toward something specific to how Terraform interacts with the Organizations API. This is the story of how we tracked down the root cause -- and why the fix isn't as simple as you'd think. What is aws_organizations_organization? Terraform's aws_organizations_organization data source retrieves information about, guess what, your AWS Organization. On the surface, it maps to the AWS DescribeOrganization API call -- a flat request. No iteration. No pagination. Simple... Or so we thought. The First Clue: Reproducing the Issue The references to the Organizations API mostly c ## Monitoring Android Vitals with the Play Developer Reporting API DevFeed: [Monitoring Android Vitals with the Play Developer Reporting API]() Original publisher: [Read original article]() Author: Julien Salvi Published: 2026-03-19T12:41:51Z Content type: tutorial Language: en Sources: [Stories by Julien Salvi on Medium]() Topics: [Android](), [API](), [Google Play](), [Gradle](), [CI/CD Pipeline](), [Google Cloud Platform (GCP)](), [Slack]() Tags: [aircall](), [android](), [android-app-development](), [anr](), [api](), [ci-cd-pipeline](), [crash](), [google-play-developer](), [gradle](), [reporting](), [slack]() ### AI overview This tutorial explains how Aircall uses the Google Play Developer Reporting API in a Gradle task to retrieve Android Vitals, including ANR and crash metrics, and deliver daily health reporting to Slack. It covers metric-set queries, timeline aggregations, service-account authentication, data modeling, and health thresholds. ### Source excerpt At Aircall, we built an automated reporting tool that fetches our Android Vitals metrics thanks to the Play Developer Reporting API and delivers a daily health dashboard straight to Slack. All of this powered by a simple Gradle task. Discovering the API The Google Play Developer Reporting API gives programmatic access to the same quality metrics you see in the Google Play Console. It covers the core Android Vitals: ANR rate, crash rate, slow start rate, and stuck background wakelocks, the signals Google uses to determine whether your app meets the bad behavior thresholds. The API is organized around metric sets that you query with a timeline specification. Each metric set returns daily, 7-day, and 28-day user-weighted aggregates, giving you the full picture from short-term regressions to long-term trends. The key advantage over scraping the Console UI is that you can automate the entire flow and integrate it into your existing CI/CD pipeline. You will find the complete API reference in the official documentation. Build with Play VitalsSetting up the dependency We chose to implement this as a Gradle task inside our build-logic module. This keeps the reporting logic close to the project without polluting the app code. First, let's add the dependency: # libs.versions.toml googleApiReporting = "v1beta1-rev20230803-2.0.0" buildLogic-plugin-google-play-developer-reporting = { module = "com.google.apis:google-api-services-playdeveloperreporting", version.ref = "googleApiReporting" } Which can then be added to the build.gradle.kts of your build-logic module: dependencies { // API to get Google Play store vitals metrics implementation(libs.buildLogic.plugin.google.play.developer.reporting) }Authenticating with a Service Account To access the API, you need a Google Cloud Service Account with the Play Developer Reporting scope. We pass the credentials as an environment variable to keep secrets out of the repository. The Reporting client initializes the API with these credentia ## Mutation testing at Mercado Libre: From pilot to everyday guardrail DevFeed: [Mutation testing at Mercado Libre: From pilot to everyday guardrail]() Original publisher: [Read original article]() Author: Luram Archanjo Published: 2026-01-14T12:19:03Z Content type: article Language: en Sources: [Mercado Libre Tech]() Topics: [mutation-testing](), [Testing](), [GitHub](), [Pull Request](), [test-coverage]() Tags: [ci-cd-pipeline](), [code-quality](), [github](), [github-action](), [mutation-testing](), [pull-requests](), [software-engineering](), [software-quality-testing](), [test-coverage](), [testing]() ### AI overview Mercado Envíos integrated mutation testing into Mercado Libre's Fury pipelines using a multi-stack GitHub Action, delta-first execution focused on modified code, and gradual team-level gates. The article explains how this approach supplements coverage by identifying weak test assertions and aims to improve pull request quality and reduce regressions. ### Source excerpt Beyond coverage: How we integrated mutation testing into Fury pipelines and turned it into an actionable quality indicator for teams At Mercado Envíos (ME), we saw that high test coverage didn't always prevent regressions -- pull requests (PRs) were green, but we still broke production. In this article, we share how we brought mutation testing into our pipelines on Fury, our internal developer platform (IDP). We used a single multi-stack GitHub Action, a delta-first approach, and gradual team-level gates. We walk through the design decisions, challenges, and lessons learned that helped us turn this technique into an everyday guardrail that improves test effectiveness and PR quality. Introduction: Green PR, still an incident Friday, end of the day. You've got a green PR, pipelines are passing, and coverage looks great. You merge with confidence. On Monday, production goes down because of an edge case no one asserted. Sounds familiar? Same here. Coverage tells us what runs, not whether tests fail where they should. You can have 95-100% line coverage and still let a subtle regression slip -- a slightly wrong if condition, an unexpected default value, a branch with no assertions. That's where mutation testing comes in. Instead of assuming tests are good just because they pass, you intentionally introduce small code changes (mutants) and check whether the test suite kills them. In mutation testing, "killing a mutant" means your test suite fails when run on the mutated code, proving it can detect the injected defect. If mutants survive, you get a concrete indicator of weak assertions exactly in the area you're changing. At Mercado Envíos (ME), we moved from a one-off experiment to making mutation testing part of teams' daily flow. We integrated it into our standard pipelines on Fury, Mercado Libre's internal developer platform. We did it without breaking delivery: a single, multi-stack GitHub Action; delta-first execution focused on modified code; and team-level gates with ## Managing Machine Identities to Reduce Anonymous Computing Risks DevFeed: [Managing Machine Identities to Reduce Anonymous Computing Risks]() Original publisher: [Read original article]() Author: jason@intellyx.com (Jason Bloomberg) Published: 2025-02-25T00:00:00Z Content type: opinion Language: en Sources: [Teleport]() Topics: [identity and access management](), [Security](), [Vulnerabilities](), [Network](), [GitHub Actions]() Tags: [ci-cd-pipeline](), [identity-and-access](), [identity-and-access-management](), [network](), [security](), [toolchain](), [vulnerabilities]() ### AI overview The article argues that anonymous computing occurs when infrastructure assets use fictitious or shared identities without identifying the human making a request. It presents machine-identity management as a way to reduce security vulnerabilities without obstructing necessary work. ### Source excerpt It's Finally Time to Embrace Trusted Computing Does your corporate network treat users on VPNs as trusted regardless of who they are? Does your web server connect to its database as a fictitious user with a password in a config file somewhere? Or perhaps the most frightening scenario: did your platform engineer log in as root to configure your CI/CD pipeline toolchain? ## CI CD for OpenHarmony Project -- GitHub Action DevFeed: [CI CD for OpenHarmony Project -- GitHub Action]() Original publisher: [Read original article]() Author: Payam Zahedi Published: 2024-12-09T12:05:48Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [GitHub Actions](), [CI/CD](), [GitHub](), [Development]() Tags: [ark-ts](), [build](), [building](), [ci-cd](), [ci-cd-pipeline](), [ci-cd-workflows](), [github](), [github-action](), [github-actions](), [harmony-os](), [open-harmony](), [sdk](), [testing](), [verify]() ### AI overview This tutorial explains how to create a GitHub Actions CI/CD workflow for building and verifying an OpenHarmony application. It introduces the roles of DevEco Studio, Hvigor, OHPM, the OpenHarmony Code Linter, and the reusable oh-action for preparing the required SDK and command-line tools. ### Source excerpt CI CD for OpenHarmony Project -- GitHub Action When developing OpenHarmony, we typically use DevEco Studio to write our code, build the project, test it, and run it on our devices, with DevEco Studio taking care of everything under the hood. However, as engineers, we love to automate repetitive processes, right? This is where CI/CD workflows become incredibly useful. GitHub Actions, in particular, is a popular and highly customizable workflow solution. In this article, we'll explore how to create a workflow on GitHub Actions to build and verify our OpenHarmony application. A Little Context To write our GitHub Action workflow, we first need to understand how DevEco Studio works under the hood. Specifically, what tools does it install, and how are they used? In this article, we won't dive too deep into all OpenHarmony tools and DevEco Studio capabilities. Instead, we'll provide a brief overview to understand the components needed for our workflow. hvigorw Hvigor is a simple build tool, much like Gradle for Android, but designed specifically for OpenHarmony apps. It helps you manage tasks, dependencies, and builds easily. DevEco Studio uses hvigorw to build, test, and run apps on devices. ohpm OHPM (OpenHarmony Package Manager) is akin to npm for JavaScript, but tailored for OpenHarmony applications. It helps facilitate the publishing, installation, and management of dependencies for shared packages. DevEco Studio uses OHPM to manage third-party libraries within OpenHarmony projects. Code Linter OpenHarmony's Code Linter is a tool that checks ArkTS and TypeScript code for best practices and coding standards. It helps developers identify and fix issues during development, ensuring high-quality code. Now that we have a good understanding of the tools involved, the next step is to bring these components together into a cohesive GitHub Action that can automate our workflow. This is where oh-action steps in. GitHub - Snapp-Mobile/oh-action: The oh-action is a GitHub Action t ## 8 tips for securing your CI/CD pipeline with Snyk DevFeed: [8 tips for securing your CI/CD pipeline with Snyk]() Original publisher: [Read original article]() Author: Eric Smalling Published: 2023-07-20T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [CI/CD](), [snyk](), [snyk-open-source](), [Application Security](), [GitHub Actions](), [Jenkins]() Tags: [application-security](), [blog](), [cheat-sheet](), [ci-cd](), [ci-cd-pipeline](), [devops](), [devrel](), [devsecops](), [enablement](), [github-actions](), [jenkins](), [security](), [snyk](), [snyk-open-source](), [snyk-platform](), [software-composition-analysis]() ### AI overview This cheat sheet presents eight tips for securing CI/CD pipelines with Snyk. It covers dependency and open-source component scanning, vulnerability detection, remediation guidance, and implementation examples for Jenkins and GitHub Actions. ### Source excerpt In this post, we'll cover using Snyk in your CI/CD pipelines to catch security issues quickly and empower your developers to fix them before they ever get to production. ## Standardize GraphQL schema linting policies with GraphOS DevFeed: [Standardize GraphQL schema linting policies with GraphOS]() Original publisher: [Read original article]() Author: Vivek Ravishankar Published: 2023-06-15T08:29:00Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [GraphOS](), [GraphQL](), [Structured-data](), [API](), [CI/CD](), [Command-line interface](), [Development](), [consistency]() Tags: [announcement](), [apis](), [ci-cd-pipeline](), [cli](), [consistency](), [graphos](), [graphql](), [lint](), [linter](), [schema]() ### AI overview Apollo GraphOS adds schema linting for GraphQL APIs. The checks validate predefined formatting and naming rules, run automatically when schema changes are published, and can also be run locally or in CI/CD pipelines with the Rover CLI. The feature is available to organizations on GraphOS Enterprise and Serverless plans. ### Source excerpt When it comes to writing code collaboratively, consistency is everything. APIs are no exception. In fact, APIs are perhaps the most important place to ensure consistency, since they act as a vein for collaboration across nearly every developer in an organization's ecosystem. For GraphQL APIs, the schema is at the heart of all collaboration and consumption, but ensuring consistency in a graph that spans many teams, tools, and workflows is no easy task. ## New Apollo Federation spec compliance tools for GraphQL Server maintainers DevFeed: [New Apollo Federation spec compliance tools for GraphQL Server maintainers]() Original publisher: [Read original article]() Author: Derek Kuc Published: 2023-01-24T08:09:00Z Content type: tutorial Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Testing](), [CI/CD](), [GitHub Actions](), [Programming](), [Docker Compose]() Tags: [apollo](), [apollo-federation](), [backend](), [ci-cd](), [ci-cd-pipeline](), [compose](), [docker](), [graphql](), [maintainers](), [npm](), [testing]() ### AI overview Apollo introduces local and CI/CD compatibility testing tools for Apollo Federation subgraph libraries. The tools are distributed as an executable NPM script and a GitHub Action, with PM2 or Docker Compose available for managing test processes. ### Source excerpt Apollo Federation is supported by over 20 different subgraph libraries across 12 different programming languages. Have you ever wondered how we capture those compatibility results? In order to ensure those libraries are compatible with the specification, we have a testing repository that verifies compatibility against their reference implementations. ## Setting Up a CI/CD Pipeline for Power BI Report Source Control DevFeed: [Setting Up a CI/CD Pipeline for Power BI Report Source Control]() Original publisher: [Read original article]() Published: 2022-11-07T00:00:00Z Content type: tutorial Language: en Sources: [Mutt0-ds Notes]() Topics: [Azure DevOps](), [CI/CD Pipeline](), [DevOps](), [REST API](), [Git](), [active directory](), [JSON](), [API](), [dataset](), [Authentication]() Tags: [authentication](), [ci-cd-pipeline](), [dataset](), [devops](), [directory](), [environment-variables](), [git](), [json](), [repository](), [rest-api]() ### AI overview This article describes setting up a CI/CD pipeline through Azure DevOps to provide rudimentary version control for Power BI reports. Because .pbix files are binary, the pipeline uploads a report to a Power BI Premium workspace, uses the Power BI REST API and Tabular Editor 2 to extract metadata, and pushes the resulting textual representation back to a Git repository. ### Source excerpt One of the most annoying issues I have when working with Power BI files is that source control is a real pain. Considering that Microsoft... ## Android CI/CD Pipeline Using GitHub Actions and Firebase Test Labs DevFeed: [Android CI/CD Pipeline Using GitHub Actions and Firebase Test Labs]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2022-03-31T00:00:00Z Content type: tutorial Language: en Sources: [Dustin Summers]() Topics: [CI/CD](), [GitHub Actions](), [GitHub](), [Android](), [Firebase]() Tags: [android](), [android-continuous-integration-continuous-delivery-cicd-github-actions-firebase-test-labs](), [ci-cd](), [ci-cd-pipeline](), [firebase](), [github](), [github-actions](), [how-to](), [tests]() ### AI overview A tutorial for configuring a CI/CD pipeline for an Android project with GitHub Actions and Firebase. It explains how to run unit, UI, code-quality, and code-smell checks on pushes and pull requests, and how to block merges until required checks pass. ### Source excerpt As a Software Engineer, knowing how to set up a solid CI/CD Pipeline for your project is a vital skill. Whether you're starting a side project or working on a well established project, having a solid CI/CD pipeline is going to enable you or your team to move faster. The end goal is to protect your branches and ensure only quality code makes it in that passes your status checks.