Merge pull request #32001 from github/repo-sync

Repo sync
github · Mar 7, 2024 · 5cb645c · 5cb645c
2 parents e137516 + 67f8b6b
commit 5cb645c
Show file tree

Hide file tree

Showing 7 changed files with 38 additions and 88 deletions.
diff --git a/content/actions/learn-github-actions/contexts.md b/content/actions/learn-github-actions/contexts.md
@@ -66,7 +66,7 @@ The following example demonstrates how these different types of variables can be
 
 {% raw %}
 
-```yaml
+```yaml copy
 name: CI
 on: push
 jobs:
@@ -286,17 +286,15 @@ jobs:
   normal_ci:
     runs-on: ubuntu-latest
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
       - name: Run normal CI
-        run: ./run-tests
+        run: echo "Running normal CI"
 
   pull_request_ci:
     runs-on: ubuntu-latest
     if: {% raw %}${{ github.event_name == 'pull_request' }}{% endraw %}
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
       - name: Run PR CI
-        run: ./run-additional-pr-ci
+        run: echo "Running PR only CI"
 ```
 
 ## `env` context
@@ -441,9 +439,8 @@ jobs:
           - 5432
 
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
       - run: pg_isready -h localhost -p {% raw %}${{ job.services.postgres.ports[5432] }}{% endraw %}
-      - run: ./run-tests
+      - run: echo "Run tests against Postgres"
 ```
 
 ## `jobs` context
@@ -562,8 +559,6 @@ jobs:
   randomly-failing-job:
     runs-on: ubuntu-latest
     steps:
-      - id: checkout
-        uses: {% data reusables.actions.action-checkout %}
       - name: Generate 0 or 1
         id: generate_number
 {%- ifversion actions-save-state-set-output-envs %}
@@ -629,7 +624,8 @@ jobs:
       - name: Build with logs
         run: |
           mkdir {% raw %}${{ runner.temp }}{% endraw %}/build_logs
-          ./build.sh --log-path {% raw %}${{ runner.temp }}{% endraw %}/build_logs
+          echo "Logs from building" > {% raw %}${{ runner.temp }}{% endraw %}/build_logs/build.logs
+          exit 1
       - name: Upload logs on fail
         if: {% raw %}${{ failure() }}{% endraw %}
         uses: {% data reusables.actions.action-upload-artifact %}
@@ -698,7 +694,7 @@ The following example contents of the `strategy` context is from a matrix with f
 This example workflow uses the `strategy.job-index` property to set a unique name for a log file for each job in a matrix.
 
 ```yaml copy
-name: Test matrix
+name: Test strategy
 on: push
 
 jobs:
@@ -709,8 +705,7 @@ jobs:
         test-group: [1, 2]
         node: [14, 16]
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
-      - run: npm test > test-job-{% raw %}${{ strategy.job-index }}{% endraw %}.txt
+      - run: echo "Mock test logs" > test-job-{% raw %}${{ strategy.job-index }}{% endraw %}.txt
       - name: Upload logs
         uses: {% data reusables.actions.action-upload-artifact %}
         with:
@@ -756,14 +751,11 @@ jobs:
         os: [ubuntu-latest, windows-latest]
         node: [14, 16]
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
       - uses: {% data reusables.actions.action-setup-node %}
         with:
           node-version: {% raw %}${{ matrix.node }}{% endraw %}
-      - name: Install dependencies
-        run: npm ci
-      - name: Run tests
-        run: npm test
+      - name: Output node version
+        run: node --version
 ```
 
 ## `needs` context
@@ -787,7 +779,7 @@ The following example contents of the `needs` context shows information for two
   "build": {
     "result": "success",
     "outputs": {
-      "build_id": "ABC123"
+      "build_id": "123456"
     }
   },
   "deploy": {
@@ -811,29 +803,24 @@ jobs:
     outputs:
       build_id: {% raw %}${{ steps.build_step.outputs.build_id }}{% endraw %}
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
       - name: Build
         id: build_step
-        run: |
-          ./build
 {%- ifversion actions-save-state-set-output-envs %}
-          echo "build_id=$BUILD_ID" >> $GITHUB_OUTPUT
+        run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT
 {%- else %}
-          echo "::set-output name=build_id::$BUILD_ID"
+        run: echo "::set-output name=build_id::$RANDOM"
 {%- endif %}
   deploy:
     needs: build
     runs-on: ubuntu-latest
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
-      - run: ./deploy --build {% raw %}${{ needs.build.outputs.build_id }}{% endraw %}
+      - run: echo "Deploying build {% raw %}${{ needs.build.outputs.build_id }}{% endraw %}"
   debug:
     needs: [build, deploy]
     runs-on: ubuntu-latest
     if: {% raw %}${{ failure() }}{% endraw %}
     steps:
-      - uses: {% data reusables.actions.action-checkout %}
-      - run: ./debug
+      - run: echo "Failed to build and deploy"
 ```
 
 ## `inputs` context
@@ -886,7 +873,7 @@ jobs:
     if: ${{ inputs.perform_deploy }}
     steps:
       - name: Deploy build to target
-        run: deploy --build ${{ inputs.build_id }} --target ${{ inputs.deploy_target }}
+        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
 ```
 
 {% endraw %}
@@ -919,7 +906,7 @@ jobs:
     if: ${{ inputs.perform_deploy }}
     steps:
       - name: Deploy build to target
-        run: deploy --build ${{ inputs.build_id }} --target ${{ inputs.deploy_target }}
+        run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}"
 ```
 
 {% endraw %}

diff --git a/...thub-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app.md b/...thub-apps/writing-code-for-a-github-app/building-ci-checks-with-a-github-app.md
@@ -595,7 +595,7 @@ If you're wondering where the terminal output above is coming from, it's written
 
 In this part, you will add the code necessary to receive `check_suite` webhook events, and create and update check runs. You'll also learn how to create check runs when a check was re-requested on {% data variables.product.prodname_dotcom %}. At the end of this section, you'll be able to view the check run you created in a {% data variables.product.prodname_dotcom %} pull request.
 
-Your check run will not perform any checks on the code in this section. You'll add that functionality in "[Part 2: Creating the Octo RuboCop CI test](#part-2-creating-the-octo-rubocop-ci-test)."
+Your check run will not perform any checks on the code in this section. You'll add that functionality in "[Part 2: Creating a CI test](#part-2-creating-a-ci-test)."
 
 You should already have a Smee channel configured that is forwarding webhook payloads to your local server. Your server should be running and connected to the {% data variables.product.prodname_github_app %} you registered and installed on a test repository.
 
@@ -714,7 +714,7 @@ In the code block that starts with `post '/event_handler' do`, where it says `#
 
 Next you'll write the `initiate_check_run` method, which is where you'll update the check run status and prepare to kick off your CI test.
 
-In this section, you're not going to kick off the CI test yet, but you'll walk through how to update the status of the check run from `queued` to `pending` and then from `pending` to `completed` to see the overall flow of a check run. In "[Part 2: Creating the Octo RuboCop CI test](#part-2-creating-the-octo-rubocop-ci-test)," you'll add the code that actually performs the CI test.
+In this section, you're not going to kick off the CI test yet, but you'll walk through how to update the status of the check run from `queued` to `pending` and then from `pending` to `completed` to see the overall flow of a check run. In "[Part 2: Creating a CI test](#part-2-creating-a-ci-test)," you'll add the code that actually performs the CI test.
 
 Let's create the `initiate_check_run` method and update the status of the check run.
 
@@ -793,7 +793,7 @@ To take advantage of requested actions, app developers can create buttons in the
 These are the steps you'll complete in this section:
 
 1. [Add a Ruby file](#step-21-add-a-ruby-file)
-1. [Clone the repository](#step-22-clone-the-repository)
+1. [Allow RuboCop to clone the test repository](#step-22-allow-rubocop-to-clone-the-test-repository)
 1. [Run RuboCop](#step-23-run-rubocop)
 1. [Collect RuboCop errors](#step-24-collect-rubocop-errors)
 1. [Update the check run with CI test results](#step-25-update-the-check-run-with-ci-test-results)
@@ -1148,7 +1148,7 @@ So far you've created a CI test. In this section, you'll add one more feature th
 
 The RuboCop tool offers the `--auto-correct` command-line option to automatically fix the errors it finds. For more information, see "[Autocorrecting offenses](https://docs.rubocop.org/rubocop/usage/basic_usage.html#autocorrecting-offenses)" in the RuboCop documentation. When you use the `--auto-correct` feature, the updates are applied to the local files on the server. You'll need to push the changes to {% data variables.product.prodname_dotcom %} after RuboCop makes the fixes.
 
-To push to a repository, your app must have write permissions for "Contents" in a repository. You already set that permission to **Read & write** back in "[Step 2.2. Cloning the repository](#step-22-clone-the-repository)."
+To push to a repository, your app must have write permissions for "Contents" in a repository. You already set that permission to **Read & write** back in "[Step 2.2. Allow RuboCop to clone the test repository](#step-22-allow-rubocop-to-clone-the-test-repository)."
 
 To commit files, Git must know which username and email address to associate with the commit. Next you'll add environment variables to store the name and email address that your app will use when it makes Git commits.
 
@@ -1164,7 +1164,7 @@ Next you'll need to add code to read the environment variables and set the Git c
 
 When someone clicks the "Fix this" button, your app receives the [check run webhook](/webhooks-and-events/webhooks/webhook-events-and-payloads#check_run) with the `requested_action` action type.
 
-In "[Step 1.3. Updating a check run](#step-13-updating-a-check-run)" you updated the `event_handler` in your `server.rb` file to look for actions in the `check_run` event. You already have a case statement to handle the `created` and `rerequested` action types:
+In "[Step 1.3. Update a check run](#step-13-update-a-check-run)" you updated the `event_handler` in your `server.rb` file to look for actions in the `check_run` event. You already have a case statement to handle the `created` and `rerequested` action types:
 
 ```ruby
 when 'check_run'
@@ -1224,7 +1224,7 @@ In the code block that starts with `helpers do`, where it says `# ADD TAKE_REQUE
     end
 ```
 
-The code above clones a repository, just like the code you added in "[Step 2.2. Clone the repository](#step-22-clone-the-repository)." An `if` statement checks that the requested action's identifier matches the RuboCop button identifier (`fix_rubocop_notices`). When they match, the code clones the repository, sets the Git username and email, and runs RuboCop with the option `--auto-correct`. The `--auto-correct` option applies the changes to the local CI server files automatically.
+The code above clones a repository, just like the code you added in "[Step 2.2. Allow RuboCop to clone the test repository](#step-22-allow-rubocop-to-clone-the-test-repository)." An `if` statement checks that the requested action's identifier matches the RuboCop button identifier (`fix_rubocop_notices`). When they match, the code clones the repository, sets the Git username and email, and runs RuboCop with the option `--auto-correct`. The `--auto-correct` option applies the changes to the local CI server files automatically.
 
 The files are changed locally, but you'll still need to push them to {% data variables.product.prodname_dotcom %}. You'll use the `ruby-git` gem to commit all of the files. Git has a single command that stages all modified or deleted files and commits them: `git commit -a`. To do the same thing using `ruby-git`, the code above uses the `commit_all` method. Then the code pushes the committed files to {% data variables.product.prodname_dotcom %} using the installation token, using the same authentication method as the Git `clone` command. Finally, it removes the repository directory to ensure the working directory is prepared for the next event.
 

diff --git a/...ub-marketplace-api-in-your-app/webhook-events-for-the-github-marketplace-api.md b/...ub-marketplace-api-in-your-app/webhook-events-for-the-github-marketplace-api.md
@@ -18,49 +18,10 @@ shortTitle: Webhook events
 
 {% data reusables.marketplace.marketplace-apps-not-actions %}
 
-## About webhooks and {% data variables.product.prodname_marketplace %}
+For more information about the {% data variables.product.prodname_marketplace %} webhook payload, see "[AUTOTITLE](/webhooks/webhook-events-and-payloads#marketplace_purchase)."
 
 Webhooks `POST` requests have special headers. See "[AUTOTITLE](/webhooks/webhook-events-and-payloads#delivery-headers)" for more details. GitHub doesn't resend failed delivery attempts. Ensure your app can receive all webhook payloads sent by GitHub. For information about how to create and disable {% data variables.product.prodname_marketplace %} webhooks, see "[AUTOTITLE](/webhooks/using-webhooks/creating-webhooks)" and "[AUTOTITLE](/webhooks/using-webhooks/disabling-webhooks)."
 
 Cancellations and downgrades take effect on the first day of the next billing cycle. Events for downgrades and cancellations are sent when the new plan takes effect at the beginning of the next billing cycle. Events for new purchases and upgrades begin immediately. Use the `effective_date` in the webhook payload to determine when a change will begin.
 
 {% data reusables.marketplace.marketplace-malicious-behavior %}
-
-## About the purchase webhook payload for {% data variables.product.prodname_marketplace %}
-
-Each `marketplace_purchase` webhook payload will have the following information:
-
-Key | Type | Description
-----|------|-------------
-`action` | `string` | The action performed to generate the webhook. Can be `purchased`, `cancelled`, `pending_change`, `pending_change_cancelled`, or `changed`. For more information, see the example webhook payloads below. **Note:** The `pending_change` and `pending_change_cancelled` payloads contain the same keys as shown in the [`changed` payload example](#example-webhook-payload-for-a-changed-event).
-`effective_date` | `string` | The date the `action` becomes effective.
-`sender` | `object` | The person who took the `action` that triggered the webhook.
-`marketplace_purchase` | `object` | The {% data variables.product.prodname_marketplace %} purchase information.
-
-The `marketplace_purchase` object has the following keys:
-
-Key | Type | Description
-----|------|-------------
-`account` | `object` | The `organization` or `user` account associated with the subscription. Organization accounts will include `organization_billing_email`, which is the organization's administrative email address. To find email addresses for personal accounts, you can use the [Get the authenticated user](/rest/users/users#get-the-authenticated-user) endpoint.
-`billing_cycle` | `string` | Can be `yearly` or `monthly`. When the `account` owner has a free GitHub plan and has purchased a free {% data variables.product.prodname_marketplace %} plan, `billing_cycle` will be `nil`.
-`unit_count`  | `integer` | Number of units purchased.
-`on_free_trial` | `boolean` | `true` when the `account` is on a free trial.
-`free_trial_ends_on` | `string` | The date the free trial will expire.
-`next_billing_date` | `string` | The date that the next billing cycle will start. When the `account` owner has a free GitHub.com plan and has purchased a free {% data variables.product.prodname_marketplace %} plan, `next_billing_date` will be `nil`.
-`plan` | `object` | The plan purchased by the `user` or `organization`.
-
-The `plan` object has the following keys:
-
-Key | Type | Description
-----|------|-------------
-`id` | `integer` | The unique identifier for this plan.
-`name` | `string` | The plan's name.
-`description` | `string` | This plan's description.
-`monthly_price_in_cents` | `integer` | The monthly price of this plan in cents (US currency). For example, a listing that costs 10 US dollars per month will be 1000 cents.
-`yearly_price_in_cents` | `integer` | The yearly price of this plan in cents (US currency). For example, a listing that costs 100 US dollars per month will be 120000 cents.
-`price_model` | `string` | The pricing model for this listing. Can be one of `FLAT_RATE`, `PER_UNIT`, or `FREE`.
-`has_free_trial` | `boolean` | `true` when this listing offers a free trial.
-`unit_name` | `string` | The name of the unit. If the pricing model is not `per-unit` this will be `nil`.
-`bullet` | `array of strings` | The names of the bullets set in the pricing plan.
-
-<br/>
diff --git a/content/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps.md b/content/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps.md
@@ -249,7 +249,7 @@ If you make more than one access token request (`POST {% data variables.product.
 
 | Error code | Description |
 |----|----|
-| `authorization_pending`| This error occurs when the authorization request is pending and the user hasn't entered the user code yet. The app is expected to keep polling the `POST {% data variables.product.oauth_host_code %}/login/oauth/access_token` request without exceeding the [`interval`](#response-parameters), which requires a minimum number of seconds between each request. |
+| `authorization_pending`| This error occurs when the authorization request is pending and the user hasn't entered the user code yet. The app is expected to keep polling the `POST {% data variables.product.oauth_host_code %}/login/oauth/access_token` request without exceeding the `interval`, which requires a minimum number of seconds between each request. |
 | `slow_down` | When you receive the `slow_down` error, 5 extra seconds are added to the minimum `interval` or timeframe required between your requests using `POST {% data variables.product.oauth_host_code %}/login/oauth/access_token`. For example, if the starting interval required at least 5 seconds between requests and you get a `slow_down` error response, you must now wait a minimum of 10 seconds before making a new request for an OAuth access token. The error response includes the new `interval` that you must use.
 | `expired_token` | If the device code expired, then you will see the `token_expired` error. You must make a new request for a device code.
 | `unsupported_grant_type` | The grant type must be `urn:ietf:params:oauth:grant-type:device_code` and included as an input parameter when you poll the OAuth token request `POST {% data variables.product.oauth_host_code %}/login/oauth/access_token`.

diff --git a/content/rest/licenses/licenses.md b/content/rest/licenses/licenses.md
@@ -1,5 +1,7 @@
 ---
-title: Licenses
+title: REST API endpoints for licenses
+shortTitle: Licenses
+allowTitleToDifferFromFilename: true
 intro: >-
   Use the REST API to retrieve popular open source licenses and information
   about a particular project's license file.

diff --git a/data/learning-tracks/admin.yml b/data/learning-tracks/admin.yml
@@ -13,8 +13,6 @@ deploy_an_instance:
     - >-
       /admin/configuration/configuring-network-settings/configuring-the-hostname-for-your-instance
     - /admin/identity-and-access-management/using-saml-for-enterprise-iam
-    - >-
-      /admin/administering-your-instance/administering-your-instance-from-the-web-ui
 upgrade_your_instance:
   title: Upgrade your instance
   description: >-

diff --git a/data/reusables/actions/github_token-input-example.md b/data/reusables/actions/github_token-input-example.md
@@ -1,17 +1,19 @@
-This example workflow uses the [labeler action](https://github.com/actions/labeler), which requires the `GITHUB_TOKEN` as the value for the `repo-token` input parameter:
+This example workflow uses the [GitHub CLI](/actions/using-workflows/using-github-cli-in-workflows), which requires the `GITHUB_TOKEN` as the value for the `GH_TOKEN` input parameter:
 
 ```yaml copy
-name: Pull request labeler
-on: [ pull_request_target ]
+name: Open new issue
+on: workflow_dispatch
 
 jobs:
-  triage:
+  open-issue:
     runs-on: ubuntu-latest
     permissions:
       contents: read
-      pull-requests: write
+      issues: write
     steps:
-      - uses: {% data reusables.actions.action-labeler %}
-        with:
-          repo-token: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
+      - run: |
+          gh issue --repo {% raw %}${{ github.repository }}{% endraw %} \
+            create --title "Issue title" --body "Issue body"
+        env:
+          GH_TOKEN: {% raw %}${{ secrets.GITHUB_TOKEN }}{% endraw %}
 ```