GitHub Models现已集成至GitHub Actions工作流，为自动化项目管理带来强大动力。文章详细介绍了三种集成方式，从基础的AI推理操作到更复杂的gh CLI扩展应用，旨在帮助开发者高效处理项目中的重复性任务，如自动分类、问题摘要生成等。通过配置必要的权限，用户可以调用多种AI模型，实现如自动请求额外信息以修复bug报告、从合并的Pull Request生成发布说明，以及定期汇总和优先排序项目问题等功能，极大地提升了开发效率和项目透明度。

🚀 **集成GitHub Models提升Actions工作流效率**：GitHub Models可直接嵌入GitHub Actions工作流，实现诸如自动化问题分类、内容摘要生成等功能，将AI能力带入项目开发流程的核心。要启用此功能，需在工作流的`permissions`块中添加`models: read`权限。

🐞 **AI辅助Bug报告信息增强**：通过`actions/ai-inference`操作，可自动化检查新提交的Bug报告是否包含足够重现问题的信息。若信息不足，AI会友善地提示作者补充，有效减少开发者在信息不全的报告上花费的时间。

📝 **自动化生成发布说明**：利用`gh-models`扩展，可以捕获已合并的Pull Request的信息（如标题、体、评论和评审），并由AI模型生成简洁的发布说明，自动添加到指定的“发布说明”Issue中，节省了手动整理发布日志的时间。

📅 **定期汇总与优先排序项目问题**：通过预设的定时触发（如每周一），结合`gh-models`和prompt文件，可以抓取一周内新增的问题，由AI进行汇总、主题提炼和优先级建议，并生成周报Issue，帮助团队更好地跟踪和管理项目进展。

GitHub Models brings AI into your GitHub Actions workflows, helping you automate triage, summarize, and more — right where your project lives. 

Let’s explore three ways to integrate and automate the use of GitHub Models in GitHub Actions workflows, from the most straightforward to the most powerful.

But first: Add the right permissions

Before you can use GitHub Models in your Actions workflows, you need to grant your workflow access to AI models. Without the correct permissions, any step that tries to call an AI model will fail.

Giving permissions to use GitHub Models is one line in your permissions block:

permissions:  contents: read  issues: write  models: read

These permissions will give your workflow the ability to read repository content; to read, create, or update issues and comments; and, most importantly for this tutorial, to enable access to GitHub Models. 

Example one: Request more information in bug reports 

This example will show you how to use the AI inference action and how to use AI to create branching logic. You can find the full workflow in this repo.

One of the most time-consuming and menial parts of our work as developers is triaging new issues that often contain too little information to reproduce. 

Instead of having to spend time assessing and responding to these issues, you can use the AI inference action lets you call leading AI models to analyze or generate text as part of your workflow. The workflow below, for example, will automatically check if new bug reports have enough information to be actionable, and respond if they’re not.

To set up the workflow, create a new file in your repository’s .github/workflows directory called bug-reproduction-instructions.yml (create the directory if it doesn’t exist). It will trigger whenever a new issue is opened and then fetch the issue’s title and body for future steps. 

name: Bug Report Reproduction Checkon:  issues:    types: [opened]permissions:  contents: read  issues: write  models: readjobs:  reproduction-steps-check:    runs-on: ubuntu-latest    steps:      - name: Fetch Issue        id: issue        uses: actions/github-script@v7        with:          script: |            const issue = await github.rest.issues.get({              owner: context.repo.owner,              repo: context.repo.repo,              issue_number: context.issue.number            })            core.setOutput('title', issue.data.title)            core.setOutput('body', issue.data.body)

Now that your workflow has the necessary context, create a new step. This step should only execute if the issue is tagged with a bug label. This step will use the AI inference action, configured with a system prompt that outlines the characteristics of effective reproduction instructions, and provide the value from the issue.

- name: Analyze Issue For Reproduction  if: contains(join(github.event.issue.labels.*.name, ','), 'bug')  id: analyze-issue  uses: actions/ai-inference@v1  with:  model: mistral-ai/ministral-3b  system-prompt: |    Given a bug report title and text for an application, return 'pass' if there is enough information to reliably reproduce the issue, meaning the report clearly describes the steps to reproduce the problem, specifies the expected and actual behavior, and includes environment details such as browser and operating system; if any of these elements are missing or unclear, return a brief description of what is missing in a friendly response to the author instead of 'pass'. Consider the following title and body:  prompt: |    Title: ${{ steps.issue.outputs.title }}    Body: ${{ steps.issue.outputs.body }}

This step will either return a pass if there is enough information provided (more on why we’re doing this in a moment), or return a response detailing what is missing. 

You can use over 40 AI models available in the GitHub Models catalog. Just swap out the model value with the identifier on each model’s page. 

Next, add one final step, which will post the comment only if the value returned was not pass. 

- name: Comment On Issue  if: contains(join(github.event.issue.labels.*.name, ','), 'bug') && steps.analyze-issue.outputs.response != 'pass'  uses: actions/github-script@v7  env:    AI_RESPONSE: steps.analyze-issue.outputs.response    with:      script: |        await github.rest.issues.createComment({          owner: context.repo.owner,          repo: context.repo.repo,          issue_number: context.issue.number,          body: process.env.AI_RESPONSE        })

By prompting the AI model to return a fixed string if certain criteria are met (in this case, a good bug report was filed with enough reproduction information), we can create AI-powered conditional logic in our workflows.

Example two: Creating release notes from merged pull requests

This example will show you how to use the gh CLI with the gh-models extension. You can find the full workflow in this repo.

Generating thorough release notes with new versions of a project can take time, between collating what’s changed and finding a succinct way to explain it to users.

But you can actually trigger GitHub Actions workflow steps  when pull requests are merged and use the GitHub CLI to gather information and take action, including calling models. The workflow below, for example, will summarize merged pull requests and add them to a release notes issue — showing how you can save time and energy with each pull request.

To set up this workflow, create a new label called release, and create one issue with this label called Publish next release changelog. Then, create a new file in your repository’s .github/workflows directory called release-notes.yml. It will trigger whenever a new pull request is closed, and its single job conditionally will run only if its merged status is true. 

name: Add to Changelogon:  pull_request:    types:      - closedpermissions:  pull-requests: read  issues: write  contents: read  models: readjobs:  add_to_changelog:    if: github.event.pull_request.merged == true    runs-on: ubuntu-latest    steps:      - name: Checkout repository        uses: actions/checkout@v4

Install the gh-models extension with a new step, providing your workflow’s token which now has permissions to use GitHub Models:

- name: Install gh-models extension  run: gh extension install https://github.com/github/gh-models  env:    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The rest of the steps will take place in one step:

- name: Summarize pull request and append to release issue  env:    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}  run: |-    PR_NUMBER="${{ github.event.pull_request.number }}"    # Fetch PR and save to a file    gh pr view "$PR_NUMBER" --json title,body,comments,reviews > pr.json        # Generate a summary using the model by reading from file    cat pr.json | gh models run xai/grok-3-mini \      "Given the following pull request information, generate a single, clear, and concise one-line changelog entry that summarizes the main change (feature, fix, or bug) introduced by this PR. Use neutral, user-facing language and avoid technical jargon or internal references. Only write the line, with no additional introduction or explanation text." > summary.md    # Fetch release issue number    RELEASE_ISSUE=$(gh issue list --label release --limit 1 --json number --jq '.[0].number')    # Fetch current release issue body    RELEASE_ISSUE_BODY=$(gh issue view "$RELEASE_ISSUE" --json body --jq '.body')    # Append summary to release issue body    FORMATTED_LINE="- $(cat summary.md) (#$PR_NUMBER)"    NEW_BODY="${RELEASE_ISSUE_BODY}"$'\n'"$FORMATTED_LINE"    # Update the release issue with the new body    gh issue edit "$RELEASE_ISSUE" --body "$NEW_BODY"

The pull request’s title, body, comments, and reviews are grabbed and passed to a model using the gh models run command. The release issue is fetched and updated with the summarized line.

Example three: summarizing and prioritizing issues

This example demonstrates how to use the ⁠GitHub CLI with the ⁠gh-models extension and a prompt file to automate a more complex, scheduled workflow. Review the full workflow file and prompt file.

It’s easy to lose track of new activity, especially as your project grows. And even then, actually keeping track of repeated issues and themes requires a surprising amount of time. To open a weekly issue to summarize, thematize, and prioritize newly opened issues, you can trigger GitHub Actions on a schedule. 

To set up the workflow, create a new file in your repository’s .github/workflows directory called weekly-issue-summary.yml. It will trigger every Monday at 9 a.m. 

name: Weekly Issue Summaryon:  workflow_dispatch:  schedule:    - cron: '0 9 * * 1'permissions:  issues: write  contents: read  models: readjobs:  create_weekly_summary:    runs-on: ubuntu-latest    steps:      - name: Checkout repository        uses: actions/checkout@v4      - name: Install gh-models extension        run: gh extension install https://github.com/github/gh-models        env:          GH_TOKEN: ${{ github.token }}

Create a new step to get open issues from the last week and save them to a file:

 - name: Get issues from the past week and summarize  id: get_issues    run: |-      LAST_WEEK=$(date -d "7 days ago" +"%Y-%m-%d")      gh search issues "created:>$LAST_WEEK" --state=open --json title,body,url --repo ${{ github.repository }} > issues.json      # further code will go here    env:      GH_TOKEN: ${{ github.token }}

Pass in the week’s worth of issues to a gh models run call:

cat issues.json | gh models run --file prompts/issue-summary.prompt.yml > summary.md

Unlike the previous example, a separate prompt file is being used by this command. Create a prompts directory in your repository and, within it, a issue-summary.prompt.yml file:

name: Issue summarizerdescription: Summarizes weekly issuesmodel: openai/gpt-4.1messages:  - role: system    content: You are a helpful issue summarizer. When given issue content, respond in markdown format.  - role: user    content: "Please summarize the following issues into a few short bullet points. Include links if provided. If possible, pull out general themes and help the team prioritize based on impact. Issues begin here:\n {{input}}"

This file contains all of the required information: the model, the system and user prompts, and, optionally, parameters used to tune your response. By using a .prompt.yml file, you can also leverage the GitHub Models’ repository integration to iterate on the prompt with a rich UI.

Back in the workflow file, straight under the gh models run command, create the issue with the summary:

ISSUE_TITLE="Issue Summary - $(date -d '7 days ago' '+%B %d') to $(date '+%B %d')"gh issue create --title "$ISSUE_TITLE" --label summary --body-file summary.md

Whether you start simple with the AI inference action, use the gh-models CLI with inline prompts, or create full-featured, prompt-driven workflows, GitHub Models makes it easy to scale your processes with AI. 

Just add the right permissions, pick an example above, and try out GitHub Models in your next workflow.

The post Automate your project with GitHub Models in Actions appeared first on The GitHub Blog.