<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:media="http://search.yahoo.com/mrss/"><channel><title>CI on Shaowen Chen's Website</title><link>https://www.chenshaowen.com/en/tags/ci/</link><description>Recent content in CI on Shaowen Chen's Website</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>&amp;copy;2016 - {year}, All Rights Reserved.</copyright><lastBuildDate>Fri, 17 Jan 2025 00:00:00 +0000</lastBuildDate><sy:updatePeriod>weekly</sy:updatePeriod><atom:link href="https://www.chenshaowen.com/en/tags/ci/atom.xml" rel="self" type="application/rss+xml"/><item><title>Building Multi-Arch Images with Nerdctl</title><link>https://www.chenshaowen.com/en/blog/use-nerdctl-to-build-multi-architecture-images.html</link><pubDate>Fri, 17 Jan 2025 00:00:00 +0000</pubDate><atom:modified>Fri, 17 Jan 2025 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/use-nerdctl-to-build-multi-architecture-images.html</guid><description>1. Installing Nerdctl Install Opscli 1 curl -sfL https://raw.githubusercontent.com/shaowenchen/ops/main/getcli.sh |VERSION=latest sh - Install Nerdctl 1 opscli task -f install-nerdctl --arch amd64 2. BuildKit Download Buildkit 1 wget https://github.com/moby/buildkit/releases/download/v0.19.0-rc2/buildkit-v0.19.0-rc2.linux-amd64.tar.gz Install Buildkit 1 2 tar xvf buildkit-*.tar.gz mv bin/* /usr/local/bin/ Configure Buildkitd 1 mkdir -p /etc/buildkit /data/buildkit 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 cat &amp;gt; /etc/buildkit/buildkitd.</description><dc:creator>微信公众号</dc:creator><category>Multi-Arch</category><category>Images</category><category>CI</category><category>Nerdctl</category><category>Kubernetes</category><category>Operations</category><category>Learning</category><category>CICD</category><category>containerd</category><category>Build</category></item><item><title>How Staged Builds Cache Third-Party Dependencies</title><link>https://www.chenshaowen.com/en/blog/how-to-cache-third-party-package-whilie-building-in-stage.html</link><pubDate>Tue, 22 Feb 2022 00:00:00 +0000</pubDate><atom:modified>Tue, 22 Feb 2022 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/how-to-cache-third-party-package-whilie-building-in-stage.html</guid><description>In a non-staged build scenario, when we use a container to build, we can mount the cache directory inside the container onto the build host, run the build task, and then copy the artifacts into the runtime image to produce the application image. But with a staged build, the build image and the runtime image live in the same Dockerfile, which makes it harder to optimize the caching of third-party dependencies.</description><dc:creator>微信公众号</dc:creator><category>CICD</category><category>CI</category><category>DevOps</category><category>Cache</category><category>Optimization</category></item><item><title>How to Connect a Remote macOS Physical Machine for Jenkins Pipeline Builds</title><link>https://www.chenshaowen.com/en/blog/how-to-run-the-pipeline-on-remote-osx.html</link><pubDate>Sun, 22 Nov 2020 00:00:00 +0000</pubDate><atom:modified>Sun, 22 Nov 2020 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/how-to-run-the-pipeline-on-remote-osx.html</guid><description>This article also applies to connecting physical machines with ARM or MIPS architectures and FreeBSD or Windows systems. If Jenkins can reach the build machine, you can skip the Frp part.
1. The Problem In scenarios where Kubernetes is the infrastructure, when Jenkins runs a build pipeline it creates a separate Pod for each pipeline for building.</description><dc:creator>微信公众号</dc:creator><category>Jenkins</category><category>macOS</category><category>CICD</category><category>CI</category><category>DevOps</category></item><item><title>How to Use Docker in Docker</title><link>https://www.chenshaowen.com/en/blog/how-to-use-docker-in-docker.html</link><pubDate>Sat, 21 Nov 2020 00:00:00 +0000</pubDate><atom:modified>Sat, 21 Nov 2020 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/how-to-use-docker-in-docker.html</guid><description>1. Typical Use Cases In CI, there is usually a CI Engine responsible for parsing the pipeline and controlling the whole build process, while the actual build is delegated to an Agent. Jenkins and GitLab both work this way.
As shown below, there are many kinds of Agents that connect to the CI Engine.</description><dc:creator>微信公众号</dc:creator><category>Docker</category><category>Kubernetes</category><category>Containers</category><category>CI</category><category>CICD</category><category>Operations</category><category>Learning</category><category>DinD</category><category>Build</category><category>Jenkins</category></item><item><title>How to Use a CDN for Further Frontend/Backend Separation - CI Scripts</title><link>https://www.chenshaowen.com/en/blog/ci-script-of-how-to-use-cdn-to-separate-frontend-and-backend-more.html</link><pubDate>Sat, 15 Sep 2018 00:00:00 +0000</pubDate><atom:modified>Sat, 15 Sep 2018 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/ci-script-of-how-to-use-cdn-to-separate-frontend-and-backend-more.html</guid><description>In a team, any change to the development workflow must be paired with the corresponding automation tooling. Without a low enough cost of use, the change is meaningless, because nobody will actually use it. In the previous post we covered how to use a CDN for further frontend/backend separation; this</description><dc:creator>微信公众号</dc:creator><category>CI</category><category>CDN</category><category>Optimization</category><category>Deployment</category><category>PaaS</category><category>Scripting</category><category>DevOps</category><category>R&amp;D</category></item><item><title>Some Common CI Scripts</title><link>https://www.chenshaowen.com/en/blog/some-common-scripts-in-ci.html</link><pubDate>Tue, 17 Jul 2018 00:00:00 +0000</pubDate><atom:modified>Tue, 17 Jul 2018 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/some-common-scripts-in-ci.html</guid><description>Because I am responsible for the team&amp;rsquo;s shared CI matters, I often need to configure CI pipelines or help others solve problems, so I put together the CI scripts I use most often for easy reference. 1. Structure of .gitlab-ci.yml Below is the structure of a GitLab CI configuration file.</description><dc:creator>微信公众号</dc:creator><category>GitLab</category><category>GitLab-CI</category><category>CI</category><category>DevOps</category><category>Continuous Integration</category><category>R&amp;D</category></item><item><title>Configuring the GitLab CI Runner</title><link>https://www.chenshaowen.com/en/blog/gitlab-ci-configuring-runner.html</link><pubDate>Tue, 08 May 2018 00:00:00 +0000</pubDate><atom:modified>Tue, 08 May 2018 00:00:00 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/gitlab-ci-configuring-runner.html</guid><description>1. Downloading and Configuring the Runner 1.1 Downloading the Runner The GitLab CI Runner is a program package written in Go; you can download it from the official site to your local machine.
1 2 yum install -y wget wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 Add execute permission
1 chmod +x /usr/local/bin/gitlab-runner 1.</description><dc:creator>微信公众号</dc:creator><category>GitLab</category><category>GitLab-CI</category><category>CI</category><category>Runner</category><category>DevOps</category><category>Operations</category></item><item><title>Jenkins Integrated GitHub Development</title><link>https://www.chenshaowen.com/en/blog/jenkins-integrated-github-development.html</link><pubDate>Tue, 18 Jul 2017 21:29:41 +0000</pubDate><atom:modified>Tue, 18 Jul 2017 21:29:41 +0000</atom:modified><guid>https://www.chenshaowen.com/en/blog/jenkins-integrated-github-development.html</guid><description>1. Basic Concepts Continuous Integration Continuous integration emphasizes that once developers commit new code, a build and (unit) test run immediately. From the test results we can determine whether the new code and the existing code integrate correctly. Continuous Delivery Building on continuous integration, continuous delivery deploys the integrated code</description><dc:creator>微信公众号</dc:creator><category>Tools</category><category>Development</category><category>Jenkins</category><category>GitHub</category><category>CI</category><category>DevOps</category><category>R&amp;D</category></item></channel></rss>