惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
博客园 - 【当耐特】
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
小众软件
小众软件
Hugging Face - Blog
Hugging Face - Blog
aimingoo的专栏
aimingoo的专栏
WordPress大学
WordPress大学
G
Google Developers Blog
博客园 - 叶小钗
大猫的无限游戏
大猫的无限游戏
P
Proofpoint News Feed
J
Java Code Geeks
U
Unit 42
云风的 BLOG
云风的 BLOG
阮一峰的网络日志
阮一峰的网络日志
N
Netflix TechBlog - Medium
宝玉的分享
宝玉的分享
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
D
Docker
V
Visual Studio Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
H
Help Net Security
V
V2EX
T
Tailwind CSS Blog

Stories by Tomas Sirio on Medium

Turing Pi 2 Home cluster Hey There! If statements on Github Actions Hello World! in ARM ISAs Hello World! in ASM x86_64 How did I boost my productivity during quarantine
Make changes on Repository A while modifying Repository B...
Tomas Sirio · 2020-10-28 · via Stories by Tomas Sirio on Medium

Tomas Sirio

Press enter or click to view image in full size

Last week at work I had an Idea which would require some files to be replicated on another repositories after I pushed them (or merged them through a pull request) on my working repository.

The example would look something like this:

As you can see, I wanted the File ‘file’ to be replicated on Repository B every single time a new copy or a modification of the existing one is pushed.

So I decided to use Github Actions for this issue. Github Actions provides you with a tool to do something on a Github event. In our case, the event would be a Push to my repository.

Github actions only requires you to create a .yaml file on the folder ./github/workflows on the route of your project. Dividing the ‘actions’ through steps, I decided to take the next approach:

Clone ProjectA and ProjectB

Replicate the file from ProjectA to ProjectB and push them to ProjectB

Push -> Clone ProjectA -> Clone ProjectB -> Copy from ProjectA the file and paste it in ProjectB -> Commit and Push on ProjectB

Let’s take a look to the .yaml file:

Things that you can skip if you are not interested in the technical side of Github Actions

As you can see. It’s a basic .yaml file. The first line determines which event you want the Action to be triggered on. Next you define the jobs (this can be modularized). Then on each job you define the steps the job will take.

In this case we ask for an ubuntu container to be created. In that container, on path ./projectA we will checkout our projectA repository while on path ./projectB we will clone our projectB repo. IMPORTANT You’ll have to define a PAT (Personal Access Token) on Github and create a secret on your projectA repository with the PAT as it’s value.

The third and fourth steps are pretty much self explanatory. If the file exists, we copy it from projectA to projectB, if it doesn’t exist (for whatever reason) we create it on projectB. Lastly we use git con projectB to push the file.

Checking the Action

Lastly, once the event is triggered, you’ll want to check out how Github is working behind the scenes. So head to the Actions tab on Github and if your workflow was rightly formatted (fingers crossed) you’ll get a window like this:

Of course, you’ll want to check if the file was replicated on your projectB repository (Because of course no one believes their solution to work on the first 100 times)

But this time, mine was :D

I’ll leave the repositories here if you want to check it out, clone it and play with it: