远程仓库.github/workflow的 yml如何配置

2024-04-25 09:20

本文主要是介绍远程仓库.github/workflow的 yml如何配置,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

git 远程仓库.github/workflow的 yml如何配置

关于远程仓库

GitHub 的协作开发方法取决于将本地存储库中的提交发布到 GitHub 以便其他人查看、获取和更新。

远程 URL 是 Git 表达“代码存储位置”的奇特方式。该 URL 可以是您在 GitHub 上的存储库,也可以是其他用户的分支,甚至是完全不同的服务器上的存储库。

  • HTTPS URL,例如 https://github.com/user/repo.git
  • SSH URL,例如 git@github.com:user/repo.git

Git 将远程 URL 与名称关联起来,默认远程通常称为 origin 。

创建远程仓库

您可以使用 git remote add 命令将远程 URL 与名称进行匹配。例如,您可以在命令行中键入以下内容:

 git remote add origin <REMOTE_URL>

这会将名称 origin 与 REMOTE_URL 相关联。

您可以使用命令 git remote set-url 更改远程 URL。

选择远程仓库的url

举例

$ git remote add origin https://github.com/OWNER/REPOSITORY.git
# Set a new remote$ git remote -v
# Verify new remote
> origin  https://github.com/OWNER/REPOSITORY.git (fetch)
> origin  https://github.com/OWNER/REPOSITORY.git (push)

使用HTTPS URLs 克隆

https:// 克隆 URL 在所有存储库上都可用,无论可见性如何。 https:// 即使您位于防火墙或代理后面,克隆 URL 也能正常工作。
当您在命令行上使用 HTTPS URL git clone 、 git fetch 、 git pull 或 git push 到远程存储库时,Git 会要求您的 GitHub 用户名和密码。当 Git 提示您输入密码时,请输入您的个人访问令牌。或者,您可以使用凭证助手,例如 Git Credential Manager。 Git 的基于密码的身份验证已被删除,取而代之的是更安全的身份验证方法。有关详细信息,请参阅“管理您的个人访问令牌”。

如果您要访问使用 SAML SSO 的组织并且使用个人访问令牌(经典),则还必须在进行身份验证之前授权您的个人访问令牌才能访问该组织。有关详细信息,请参阅“关于使用 SAML 单点登录进行身份验证”和“授权个人访问令牌以用于 SAML 单点登录”。

  1. 您可以使用凭证助手,以便 Git 每次与 GitHub 对话时都会记住您的 GitHub 凭证。有关更多信息,请参阅“在 Git 中缓存 GitHub 凭证”。

Git Credential Manager (GCM) 是安全存储凭据并通过 HTTPS 连接到 GitHub 的另一种方法。使用 GCM,您无需手动创建和存储个人访问令牌,因为 GCM 代表您管理身份验证,包括 2FA(双因素身份验证)。

下次您克隆需要身份验证的 HTTPS URL 时,Git 将提示您使用浏览器窗口登录。可能首先会要求您授权 OAuth 应用程序。如果您的帐户或组织需要双因素身份验证,您还需要完成 2FA 挑战。
成功进行身份验证后,您的凭据将存储在 macOS 钥匙串中,并在您每次克隆 HTTPS URL 时使用。 Git 不会要求您再次在命令行中输入凭据,除非您更改凭据。

使用 Homebrew 安装 Git:

brew install git

使用 Homebrew 安装 GCM:

brew install --cask git-credential-manager

  1. 要克隆存储库而不在命令行上向 GitHub 进行身份验证,您可以使用 GitHub Desktop 进行克隆。有关更多信息,请参阅“将存储库从 GitHub 克隆到 GitHub Desktop”。

使用SSH URLs

SSH URL 提供通过 SSH(一种安全协议)对 Git 存储库的访问。要使用这些 URL,您必须在计算机上生成 SSH 密钥对,并将公钥添加到您在 GitHub.com 上的帐户。有关详细信息,请参阅“使用 SSH 连接到 GitHub”。

当您使用 SSH URL git clone 、 git fetch 、 git pull 或 git push 访问远程存储库时,系统会提示您输入密码并且必须提供您的 SSH 密钥密码。有关详细信息,请参阅“使用 SSH 密钥密码”。

如果您要访问使用 SAML 单点登录 (SSO) 的组织,则必须先授权 SSH 密钥才能访问该组织,然后再进行身份验证。有关更多信息,请参阅 GitHub Enterprise Cloud 文档中的“关于使用 SAML 单点登录进行身份验证”和“授权 SSH 密钥与 SAML 单点登录一起使用”。

提示:您可以使用 SSH URL 将存储库克隆到您的计算机,或者作为将代码部署到生产服务器的安全方法。您还可以将 SSH 代理转发与部署脚本结合使用,以避免管理服务器上的密钥。有关详细信息,请参阅“使用 SSH 代理转发”。

GitHub Actions 的工作流配置

在 GitHub Actions 的工作流配置中使用的 github_token 字段是用来提供访问 GitHub API 的认证信息。它代表了一个特定的权限令牌(Token),通常用于在 GitHub Actions 自动化过程中授权对 GitHub 仓库进行操作,比如推送代码、访问仓库数据等。

GitHub Token 的类型

  • GITHUB_TOKEN: 这是由 GitHub 自动创建并提供给运行中的 GitHub Actions 工作流的一个特殊令牌。这个令牌具有与触发工作流的 GitHub 用户或 GitHub App 关联的权限。它主要用于权限验证,让工作流可以安全地与 GitHub 仓库交互。GITHUB_TOKEN 的权限默认受限于与它关联的仓库,并且在工作流结束时失效,确保安全性。

  • 个人访问令牌(PAT): 这是用户手动在 GitHub 账户设置中生成的令牌,可以具有更广泛的权限,并可以跨多个仓库使用。与 GITHUB_TOKEN 不同,PAT 的使用不限于单个工作流会话,而是直到它被用户撤销或过期。使用 PAT 可以在工作流中执行更多操作,如在不同的仓库之间推送代码等。

在 GitHub Actions 中使用 Token

在 GitHub Actions 的 YAML 配置文件中,你可以这样使用 Token:

steps:- uses: actions/checkout@v2- name: Some step that uses the GitHub tokenuses: some-action-that-needs-token@v1with:token: ${{ secrets.GITHUB_TOKEN }}  # 使用自动生成的 GITHUB_TOKEN

如果你需要使用 PAT 或自定义命名的密钥,你可以将其存储在 GitHub 仓库的 Secrets 中,并在工作流中引用它:

steps:- uses: actions/checkout@v2- name: Some step that uses a custom PATuses: some-action-that-needs-token@v1with:token: ${{ secrets.PAT }}  # 使用存储在 Secrets 中的个人访问令牌

重要事项

  • 使用 GITHUB_TOKEN 时,要注意它的权限可能受限,可能不足以执行一些跨仓库的操作。
  • 使用 PAT 时,要格外小心,因为它通常权限较高,泄露后可能导致安全风险。
  • 确保在 GitHub 的 Secrets 设置中正确配置和保护你的 Token,避免将 Token 硬编码在工作流文件中。

通过正确使用这些 Token,你的 GitHub Actions 工作流可以安全地与 GitHub 交互,执行各种自动化任务。如果还有疑问或需要进一步的帮助,请随时联系。

在github操作步骤

在 GitHub 中,GITHUB_TOKEN 和个人访问令牌(PAT)是两种用于身份验证和授权的令牌,它们的生成和使用方式有所不同。以下是详细的生成方法和相关注意事项:

1. GITHUB_TOKEN

GITHUB_TOKEN 是自动由 GitHub 在每次 GitHub Actions 工作流运行时生成的。你不需要手动创建这个令牌。它会自动注入到工作流环境中,并且仅在当前工作流运行期间有效。

使用方法

  • 在你的 GitHub Actions 工作流文件中,你可以直接引用 GITHUB_TOKEN,如下所示:

    steps:- name: Example using GITHUB_TOKENuses: some-actionwith:token: ${{ secrets.GITHUB_TOKEN }}
    
  • 这个令牌的权限通常受限于关联的仓库,并且具有足够的权限执行大多数与仓库相关的操作,如克隆、推送、拉取等。

2. 个人访问令牌(PAT)

个人访问令牌(PAT)需要你手动在 GitHub 账户设置中生成。它可以具有广泛的权限,并可以跨仓库使用。由于它的权限较广,因此需要更谨慎地处理。

生成步骤

  1. 登录到 GitHub:打开你的浏览器,访问 GitHub 并登录。
  2. 访问设置:在页面右上角,点击你的头像,然后选择“Settings”(设置)。
  3. 开发者设置:在设置页面的侧边栏中,找到“Developer settings”(开发者设置)并点击。
  4. 访问令牌:在开发者设置页面中,选择“Personal access tokens”(个人访问令牌),然后点击“Generate new token”(生成新令牌)。
  5. 选择权限:给你的令牌命名,并选择适当的权限。对于大多数用于 CI/CD 的操作,你可能需要选择 repo 权限。确保选择的权限符合你的需求,并尽量遵循最小权限原则。
  6. 生成令牌:完成后,点击页面底部的“Generate token”(生成令牌)按钮。
  7. 复制并保存令牌:生成后,你将看到一次性显示的令牌。确保复制并安全地保存这个令牌,因为它不会再次显示。

存储和使用

  • 将生成的 PAT 添加到 GitHub 仓库的 Secrets 中,方法与之前类似,然后在 GitHub Actions 中引用该 Secret,如下所示:

    steps:- name: Example using PATuses: some-actionwith:token: ${{ secrets.YOUR_PAT_SECRET_NAME }}
    

安全注意事项

  • 保密性:永远不要将令牌硬编码在代码中或公开令牌。始终使用 GitHub Secrets 来管理敏感数据。
  • 权限:为 PAT 选择尽可能低的权限级别,以减少安全风险。

通过以上步骤,你可以正确生成和使用 GITHUB_TOKEN 和 PAT,以安全地实现自动化操作和其他需要 GitHub API 授权的任务。如果有任何疑问或需要进一步的帮助,请随时联系。

下面展示一下我的yml 例子

name: SSH CI Github Pages
on:#监听push操作push:branches:- main # 这里只配置了main分支,所以只有推送main分支才会触发以下任务
jobs:# 任务IDbuild-and-deploy:# 运行环境runs-on: ubuntu-latest# 步骤steps:# 官方action,将代码拉取到虚拟机- name: Checkout  ️ uses: actions/checkout@v2with:persist-credentials: false  # 这个设置很重要,尤其是在部署到 public repository 时- name: Setup SSH keysuses: webfactory/ssh-agent@v0.5.3with:ssh-private-key: ${{ secrets.DEPLOY_KEY }}- name: Setup Node.jsuses: actions/setup-node@v2with:node-version: '18'# cache: 'pnpm'- name: Install pnpmrun: |npm install -g pnpm@6.32.11echo "Verify pnpm version"pnpm -v- name: Add pnpm to PATHrun: echo "$(npm prefix -g)/bin" >> $GITHUB_PATH- name: Cache pnpm modulesuses: actions/cache@v2with:path: |~/.pnpm-storekey: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }}restore-keys: |${{ runner.os }}-pnpm-- name: Install dependenciesrun: pnpm install- name: Buildrun: pnpm run docs:build- name: Deploy   # 部署uses: peaceiris/actions-gh-pages@v4with:# branch: gh-pages # 部署后提交到那个分支# github_token: ${{ secrets.PAT }}deploy_key: ${{ secrets.DEPLOY_KEY }} #公钥publish_dir: ./site/docs/.vitepress/dist # 这里填打包好的目录名称publish_branch: gh-pages
  • GitHub Actions 自动部署前端 Vue 项目
  • 使用Github Actions自动部署vue项目

这篇关于远程仓库.github/workflow的 yml如何配置的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/934281

相关文章

java实现docker镜像上传到harbor仓库的方式

《java实现docker镜像上传到harbor仓库的方式》:本文主要介绍java实现docker镜像上传到harbor仓库的方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地... 目录1. 前 言2. 编写工具类2.1 引入依赖包2.2 使用当前服务器的docker环境推送镜像2.2

一文详解Git中分支本地和远程删除的方法

《一文详解Git中分支本地和远程删除的方法》在使用Git进行版本控制的过程中,我们会创建多个分支来进行不同功能的开发,这就容易涉及到如何正确地删除本地分支和远程分支,下面我们就来看看相关的实现方法吧... 目录技术背景实现步骤删除本地分支删除远程www.chinasem.cn分支同步删除信息到其他机器示例步骤

Linux中SSH服务配置的全面指南

《Linux中SSH服务配置的全面指南》作为网络安全工程师,SSH(SecureShell)服务的安全配置是我们日常工作中不可忽视的重要环节,本文将从基础配置到高级安全加固,全面解析SSH服务的各项参... 目录概述基础配置详解端口与监听设置主机密钥配置认证机制强化禁用密码认证禁止root直接登录实现双因素

嵌入式数据库SQLite 3配置使用讲解

《嵌入式数据库SQLite3配置使用讲解》本文强调嵌入式项目中SQLite3数据库的重要性,因其零配置、轻量级、跨平台及事务处理特性,可保障数据溯源与责任明确,详细讲解安装配置、基础语法及SQLit... 目录0、惨痛教训1、SQLite3环境配置(1)、下载安装SQLite库(2)、解压下载的文件(3)、

Linux如何快速检查服务器的硬件配置和性能指标

《Linux如何快速检查服务器的硬件配置和性能指标》在运维和开发工作中,我们经常需要快速检查Linux服务器的硬件配置和性能指标,本文将以CentOS为例,介绍如何通过命令行快速获取这些关键信息,... 目录引言一、查询CPU核心数编程(几C?)1. 使用 nproc(最简单)2. 使用 lscpu(详细信

Nginx 重写与重定向配置方法

《Nginx重写与重定向配置方法》Nginx重写与重定向区别:重写修改路径(客户端无感知),重定向跳转新URL(客户端感知),try_files检查文件/目录存在性,return301直接返回永久重... 目录一.try_files指令二.return指令三.rewrite指令区分重写与重定向重写: 请求

Nginx 配置跨域的实现及常见问题解决

《Nginx配置跨域的实现及常见问题解决》本文主要介绍了Nginx配置跨域的实现及常见问题解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来... 目录1. 跨域1.1 同源策略1.2 跨域资源共享(CORS)2. Nginx 配置跨域的场景2.1

gitlab安装及邮箱配置和常用使用方式

《gitlab安装及邮箱配置和常用使用方式》:本文主要介绍gitlab安装及邮箱配置和常用使用方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1.安装GitLab2.配置GitLab邮件服务3.GitLab的账号注册邮箱验证及其分组4.gitlab分支和标签的

MySQL MCP 服务器安装配置最佳实践

《MySQLMCP服务器安装配置最佳实践》本文介绍MySQLMCP服务器的安装配置方法,本文结合实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下... 目录mysql MCP 服务器安装配置指南简介功能特点安装方法数据库配置使用MCP Inspector进行调试开发指

Redis Cluster模式配置

《RedisCluster模式配置》:本文主要介绍RedisCluster模式配置,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录分片 一、分片的本质与核心价值二、分片实现方案对比 ‌三、分片算法详解1. ‌范围分片(顺序分片)‌2. ‌哈希分片3. ‌虚