Github-Actions

人们在网上首先发现你的中央是哪里？兴许你的社交媒体是人们搜寻你时首先发现的货色，亦兴许是你为本人创立的投资组合网站。然而，如果你应用GitHub来分享你的代码并参加开源我的项目，那么你的GitHub个人主页可能是人们为了理解你而去的第一个中央。 你心愿你的GitHub个人主页说些什么？你心愿如何以扼要易读的形式向访客表白对你的重要性以及你是谁？无论他们是将来的雇主还是开源我的项目的潜在合作伙伴，你都必须领有一个引人注目的个人主页。 应用GitHub Actions，你能够把一个动态的markdown文档变成一个动静的、放弃对你最新信息更新的良好体验。那么如何做到这一点呢？ 我将向你展现一个例子，通知你如何在不费吹灰之力的状况下迅速做到这一点。在这个例子中，你将学习如何抓取一个网站并应用这些数据来动静更新你的GitHub个人主页。咱们将在Ruby中展现这个例子，但你也能够用JavaScript、TypeScript、Python或其余语言来做。 GitHub个人主页如何运作你的GitHub个人主页能够通过在网页浏览器中拜访github.com/[你的用户名]找到。那么该页面的内容来自哪里？ 它存在于你账户中一个非凡的仓库中，名称为你的账户用户名。如果你还没有这个仓库，当你拜访github.com/[你的用户名]时，你不会看到任何非凡的内容，所以第一步是确保你曾经创立了这个仓库，如果你还没有，就去创立它。 摸索仓库中的文件仓库中惟一须要的文件是README.md文件，它是你的个人主页页面的起源。 ./├── README.md持续在这个文件中增加一些内容并保留，刷新你的用户名主页，你会看到这些内容反映在那里。 为动静内容增加正确的文件夹在咱们创立代码以使咱们的个人主页动态化之前，让咱们先增加文件夹构造。 在顶层增加一个名为.github的新文件夹，在.github外部增加两个新的子文件夹：scripts/和workflows/。 你的文件构造当初应该是这样的： ./├── .github/│ ├── scripts/│ └── workflows/└── README.md制作一个动静个人主页对于这个例子，咱们须要做三件事： 在README中定义一个搁置动静内容的中央在scripts/中增加一个脚本，用来实现爬取工作在workflows/中为GitHub Actions增加一个工作流，按计划运行该脚本当初让咱们逐渐实现。 更新README咱们须要在README中减少一个局部，能够用正则来抓取脚本进行批改。它能够是你的具体应用状况所须要的任何内容。在这个例子中，咱们将在README中增加一个最近博客文章的局部。 在代码编辑器中关上README.md文件，增加以下内容： ### Recent blog posts当初咱们有了一个供脚本查找的区域。 创立脚本咱们正在构建的示例脚本是用Ruby编写的，应用GitHub gem octokit与你的仓库进行交互，应用nokogiri gem爬取网站，并应用httparty gem进行HTTP申请。 在上面这个例子中，要爬取的元素曾经被确定了。在你本人的用例中，你须要明确你想爬取的网站上的元素的门路，毫无疑问它将不同于上面显示的在 posts 变量中定义的，以及每个post的每个title和link。 上面是示例代码，将其放在scripts/文件夹中： require 'httparty'require 'nokogiri'require 'octokit'# Scrape blog posts from the websiteurl = "<https://www.bengreenberg.dev/blog/>"response = HTTParty.get(url)parsed_page = Nokogiri::HTML(response.body)posts = parsed_page.css('.flex.flex-col.rounded-lg.shadow-lg.overflow-hidden')# Generate the updated blog posts list (top 5)posts_list = ["\n### Recent Blog Posts\n\n"]posts.first(5).each do |post| title = post.css('p.text-xl.font-semibold.text-gray-900').text.strip link = "<https://www.bengreenberg.dev#{post.at_css('a')[:href]}>" posts_list << "* [#{title}](#{link})"end# Update the README.md fileclient = Octokit::Client.new(access_token: ENV['GITHUB_TOKEN'])repo = ENV['GITHUB_REPOSITORY']readme = client.readme(repo)readme_content = Base64.decode64(readme[:content]).force_encoding('UTF-8')# Replace the existing blog posts sectionposts_regex = /### Recent Blog Posts\n\n[\s\S]*?(?=<\/td>)/mupdated_content = readme_content.sub(posts_regex, "#{posts_list.join("\n")}\n")client.update_contents(repo, 'README.md', 'Update recent blog posts', readme[:sha], updated_content)正如你所看到的，首先向网站收回一个HTTP申请，而后收集有博客文章的局部，并将数据调配给一个posts变量。而后，脚本在posts变量中遍历博客文章，并收集其中的前5个。你可能想依据本人的须要扭转这个数字。每循环一次博文，就有一篇博文被增加到post_list的数组中，其中有该博文的题目和URL。 ...

前言这两天看到墨渊君大佬的一篇文章 GitHub 主页丑化 & 显示掘金最近公布文章 Top10 ，次要是在讲怎么丑化 github 主页的，有趣味能够看看。其中有一项是讲如何配置 github action，从而将掘金最新公布的篇文章同步到主页。所以我也有样学样，很快就配置好并且同步胜利，相似这样： 但目前仅反对工夫和题目，没有点赞数、珍藏等等，且不反对其余平台，如知乎、思否，刚好我最近也在接触 github action，所以就想着看看大佬是怎么实现的，而后实现一个满足本人需要的。 牛曾经吹上了天，看起来不做是不行了。不过还好，通过一天的折腾，终于实现了大部分性能，并且开源在 github：baozouai/multi-platform-posts-action。 目前该 action 反对的性能有： 多平台，目前反对掘金、知乎、思否（原本做好了语雀的，但发现语雀接口很奇怪，没法拿到正确的文章链接，所以临时勾销反对语雀的性能）反对生成不同平台的 icon 反对点赞数 反对珍藏数 ⭐（目前只有 juejin 有，知乎、思否接口比拟麻烦，暂且不做）原本还有个文章封面的，然而生成后github首页太长了，所以就放弃该性能了那接下来就为大家介绍如何配置，疾速丑化你的 github 主页~ 丑化 github 主页新建 github 主页仓库如果曾经有主页仓库，能够跳过这部分。如果还不晓得 github 主页是啥，能够看下我的 主页实际上也是一个仓库，如果你没有的话，能够新建，要求是跟你的 github 同名： 大抵意思是：baozuai/baozuai 是一个 ✨ 非凡的 ✨ 存储库，您能够应用它将 README.md 增加到您的 GitHub 配置文件中。请确保它是公共的，并应用自述文件对其进行初始化以开始操作。 在你的 readme 外面增加占位符因为咱们要将对应平台的文章主动生成到 github，所以须要一个占位符，生成之后间接替换即可，即在你的 readme.md 中增加以下占位符： <!-- multi-platform-posts start -->这里会插入生成的不同平台的文章列表<!-- multi-platform-posts end -->配置你的 github action，增加 update_readme.yml如果还不晓得怎么增加工作流，能够看我的主页仓库，增加的地位如下： ...

一 本文目标记录如何通过 Github Action 实现 SpringBoot 我的项目的自动化公布。其中 SpringBoot 我的项目通过 Docker 进行治理。 二 Github Action 须要的次要步骤设置 Java 环境并通过 Maven 进行我的项目构建构建 Docker 镜像并推送到公有镜像仓库登录近程服务器，拉取镜像并重启服务三 设置 Java 环境并通过 Maven 进行我的项目构建这里应用 JDK 11 并设置 maven 缓存放慢构建工夫。其中 -DskipTests=true 示意构建时跳过测试。如果须要测试能够删掉这个参数。 - name: Set up JDK 11 uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' cache: maven- name: Build with Maven run: mvn -B -DskipTests=true package --file pom.xml四 构建 Docker 镜像并推送到公有镜像仓库这里次要解决的问题是怎么抉择 Docker 公有镜像，抉择有下 名称长处毛病Github Package收费，和 Github 高度集成，配置不便我国大陆云服务器连贯 Github 太 TM 慢Docker 官网Docker 官网，值得信赖，大陆云服务器连贯速度 OK只反对一个公有镜像仓库，多了要钱Coding.net大陆云服务器连贯速度快，收费，被腾讯收了，服务应该不会中断配置稍微简单但能够承受我最终的抉择是 Coding.net，但如果云服务器容许，我会抉择 Github Package。 ...

GitHub Action 继续集成服务推出有一段时间了，目前曾经收费凋谢应用，因为集体我的项目都是放在Github上有点多，应用它来公布、测试、部署，是极大的进步了生产力。 上面通过一些实例来阐明，咱们能够在那些中央能够进步生产力。 入门咱们只须要在我的项目的 .github/workflows/ 目录下配置 yml 文件，配置触发事件既能够，例如 .github/workflows/ci.yml 中，咱们在 master 分支进行 push，就能够登程这个工作流。 name: CIon: push: branches: - master为这个工作流增加一些工作，通过应用 actions/checkout 拉代码，应用 actions/setup-node 装置制订的 nodejs 版本 name: CIon: push: branches: - masterjobs: build-deploy: runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 14你能够增加更多的步骤实现简略的测试，例如装置依赖，编译代码，运行测试用例等： jobs: build-deploy: runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: 14 - run: npm install - run: npm run build - run: npm run coverage - run: npm run bundle - run: npm run bundle:min - run: npm run doc主动打 tag配置一个步骤，通过判断 package.json 中的变动主动创立一个 tag。 ...

前言-学以致用之前始终忙于开发，总是零散的去看一些货色，想想学货色了么？额... 如同学了，又如同没有学，不晓得你们有没有这种感觉，所以新年初始，换一种学习办法，本着学以致用去残缺的学一些货色，正好之前想接触CI,CD 这里的常识，所以就从最常见的github开始吧，毕竟收费又罕用。 初始化我的项目创立github代码仓库，clone 我的项目到本地，进入目录初始化我的项目 npx create-react-app而后依照命令提醒输出实现初始化,推送我的项目到github。 配置github actions指标是实现推送代码到master分支, 主动开始构建我的项目，部署到Gthub Pages。依照文档先跑起来第一个流程，让本人看到成果，在去学习语法内容，这样更能激发趣味，省得间接看文档看睡着了... 在目录外层减少 .gihub/workflows文件夹，创立第一个first-demo.yml文件，拷贝示例内容.name: GitHub Actions Demoon: [push]jobs: Explore-GitHub-Actions: runs-on: ubuntu-latest steps: - run: echo " The job was automatically triggered by a ${{ github.event_name }} event." - run: echo " This job is now running on a ${{ runner.os }} server hosted by GitHub!" - run: echo " The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}." - name: Check out repository code uses: actions/checkout@v2 - run: echo " The ${{ github.repository }} repository has been cloned to the runner." - run: echo "️ The workflow is now ready to test your code on the runner." - name: List files in the repository run: | ls ${{ github.workspace }} - run: echo " This job's status is ${{ job.status }}."提交代码，点击gihub仓库上方的Actions按钮，查看成果，第一个工作流程就实现了。 开始编写本人的yml文件,实现主动构建疾速过一遍文档，学习一下语法，实现本人想要的工作流程。从demo能够看到次要有流程有这么几步 ...

先来看一个场景 在 Github 有一个我的项目 ，简要的构造如下 构造 简略解释一下这张图： 这个我的项目，由一个私有我的项目和一个公有我的项目组成，通过 git submodule 2者之间链接在了一起。 它们都有很多的 Actions , 比方: deploy 负责公布工作。push 负责被动推送link给各大搜索引擎。sync 负责解析 markdown 并通过 md5 摘要比对，同步批改到近程数据库里。action trigger 负责近程触发其余仓库的 action。然而，由图上可知， Actions 是扩散在 2 个仓库里的，一个私有，一个公有。它们这些 Actions 如何进行权限验证和通信呢？ 在这里, 我次要通过图中橙色那两个箭头 submodule, remote ， 通过他们对 deploy 这个 action 的影响，来和大家简略的聊聊解决方案。 actions/checkout checkout 想必是用的最多的 action 之一了 有了它，编写的 workflow 才有权限去拜访咱们的仓库。 咱们往往应用的时候，就写那么一行 - uses: actions/checkout@v2这一行的默认配置，应用是获取以后 $GITHUB\_WORKSPACE 下的仓库文件。 显然它的性能不仅如此，它也能够获取任意仓库，只有咱们给它提供受权。 拜访公有仓库 由图上可知，咱们私有仓库里，附加了一个公有仓库作为子模块。 这时候应用 checkout 的默认受权，可能获取公有子模块仓库的代码吗？ 显然是不能的，如图所示： fatal 所以，咱们要给 checkout action 进行受权，让它有权限去获取 private submodule Q: 怎么受权？ A: PAT (personal access token) 增加步骤：Settings -> Developer settings -> Personal access tokens -> Generate new token 同时确保 PAT 有 Full control of private repositories 的能力。 scopes 在获取 token 之后，就能够: - uses: actions/checkout@v2  with:    # Default: ${{ github.token }} ,传参给它更高权限的 token    token: ${{ secrets.PERSONAL_TOKEN }}    # 把子模块关上    submodules: 'true'于是就能在 public 的action 里轻松的拜访 private 的 repo 了。 success Workflow dispatch event 下一个问题： Q: 怎么在公有的B仓库里，触发私有的A仓库的 Action 呢？ A: REST+PAT 受权，近程调用触发 这个大家都十分相熟了，办法上无非是把 token 作为受权，去调用一个接口，在传参校验胜利之后，action 就跑起来了，大家看到的那些 openapi,云厂商的 SDK 都是这么做的。 Github 也是如此, 上图。 申明可触发 首先须要在 workflows 文件里，加一行： on:  workflow_dispatch:代表此 action 可被 workflow event 触发。 接着就能够进行下一步。 RESTful API ...

应用 GitHub Action 公布版本时, 获取触发的 tag 作为公布的版本号. 形式一通过 step 获取 tag, 在须要应用的中央应用 steps.get_version.outputs.VERSION,其中 get_version 是 step 的 id. name: Releaseon: push: tags: - 'v*'jobs: release: name: Release runs-on: ubuntu-latest steps: - name: Get version id: get_version run: echo ::set-output name=VERSION::${GITHUB_REF/refs\/tags\//} - name: Create Release uses: actions/create-release@v1 env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} with: tag_name: ${{ steps.get_version.outputs.VERSION }} release_name: ${{ steps.get_version.outputs.VERSION }} draft: false prerelease: false形式二间接应用 github.ref (触发条件为 tag). ...

前言GitHub Actions 是 GitHub 推出的性能，能够为咱们的我的项目构建自动化工作流。例如代码查看，自动化打包，测试，公布版本等等。入口在我的项目 Pull Requests 旁边。 本篇文章次要是趟一遍其中的小坑，让大家在第一次应用的时候能比较顺利的跑通。其中次要用到了 GitHub，Docker，SpringBoot，Nginx 等技术。对这些技术还不是很理解的搭档，能够先自行查阅一下材料哈。???? 实际步骤创立 SpringBoot 工程应用 IDEA 创立一个 SpringBoot 工程，SpringBoot 从 2.3.0.M1 版本开始用 Gradle 构建。所以咱们这里也选 Gradle 作为构建工具 ????。 We made a fairly significant change to Spring Boot in 2.3.0.M1. It was the first release of the project to be built with Gradle rather than Maven.???? 详情可参考 Migrating Spring Boot’s Build to Gradle 在 SpringBoot 工程中，咱们编写一个简略的控制器用于测试，代码非常简略，这里也给出示例。 @RestControllerpublic class DemoController { @GetMapping("/") public String sayHello() { return "Hello GitHub Actions!"; }}编写 Dockerfile 文件在 SpringBoot 工程中创立 Dockerfile 文件，用于镜像打包 ????。 ...

近来手痒，又陷入了自我捣腾的无限循环。 其实事情是这样的，最近阿里云搞活动（嗯，友情打广告），229买了个3年版低配服务器；前端时间写用React + Github Graphql API自定义你的博客, 见识了Github Action的强大，所以就尝试打造自己的前端构建部署工作流程；也许你看到过很多大厂的前端自动构建部署，但鲜有尝试，今天就可以自己动手啦，撸起来吧。 从workflow看流程定制后的Github Action workflow大概长这样： name: Deploy static source to my serveron: push: branches: -masterjobs: build: runs-on: ubuntu-latest steps: - name: checkout uses: actions/checkout@v1 - name: build run: npm install && npm run pub - name: deploy uses: closertb/deploy-static-action@master with: name: 'doddle' token: ${{ secrets.Deploy_Token }} requestUrl: 'http://114.55.38.249:8080/operate/deploy' dist: 'dist' target: 'adminManage'大概流程是这样： 监听master分支的push操作；checkout：新建构建分支build：依赖安装，打包构建deploy：将上一步的构建产物，打包部署到你的服务器静态资源文件中over部署的实现思路构建很简单，就是打包，这种工具很多，什么script-build， roadhog，或自定义webpack。这里主要说部署；其实部署也很简单，看图： 嗯，部署也讲完了。详细实现过程看参见我自定义的action：deploy-static-action 关于上面的几个构建参数： name：一个名字，自己随便啦，根据自己需要token：这个比较重要，服务器的通关口令。这里最好的方式是通过项目的secrets来设置dist：构建打包后的文件夹名，会根据这个文件夹名来获取其中的构建产物， 默认是disttarget：静态资源的目标文件夹名， 默认是distrequestUrl：一个部署API关于上传服务器deploy-static-action其实只做了部署中的构建产物收集，真正的部署其实是依赖requestUrl来实现的，所以要实现 http://114.55.38.249:8080/operate/deploy 这个服务也很重要，你可以重用我的deploy-static-action，但部署API不能，因为这个API是给我的服务器私有定制的。不过我可以提供示例代码参考： 参考代码, deploy.js ...