Cl#2

.github/CONTRIBUTING.md

@@ -6,9 +6,10 @@ We accept pull requests for bug fixes and features where we've discussed the app
 
 Please do:
 
-* Check existing issues to verify that the [bug][bug issues] or [feature request][feature request issues] has not already been submitted.
+* Check issues to verify that a [bug][bug issues] or [feature request][feature request issues] issue does not already exist for the same problem or feature.
 * Open an issue if things aren't working as expected.
 * Open an issue to propose a significant change.
+* Open an issue to propose a design for an issue labelled [`needs-design` and `help wanted`][needs design and help wanted], following the [proposing a design guidelines](#proposing-a-design) instructions below.
 * Open a pull request to fix a bug.
 * Open a pull request to fix documentation about a command.
 * Open a pull request for any issue labelled [`help wanted`][hw] or [`good first issue`][gfi].
@@ -52,7 +53,21 @@ We generate manual pages from source on every release. You do not need to submit
 
 ## Design guidelines
 
-You may reference the [CLI Design System][] when suggesting features, and are welcome to use our [Google Docs Template][] to suggest designs.
+### Proposing a design
+
+You may propose a design to solve an open bug or feature request issue that has both [the `needs-design` and `help-wanted` labels][needs design and help wanted].
+
+To propose a design:
+
+- Open a new issue using the [design proposal issue template](./ISSUE_TEMPLATE/submit-a-design-proposal.md).
+- Include a link to the issue that the design is for.
+- Describe the design you are proposing to resolve the issue, leveraging the [CLI Design System][].
+- Mock up the design you are proposing using our [Google Docs Template][] or code blocks.
+  - Mock ups should cleary illustrate the command(s) being run and the expected output(s).
+
+### (core team only) Revewing a design
+
+A member of the core team will [triage](../docs/triage.md) the design proposal. Once a member of the core team has reviewed the design, they may add the [`help wanted`][hw] label to the issue, so a PR can be opened to provide the implementation.
 
 ## Resources
 
@@ -62,6 +77,7 @@ You may reference the [CLI Design System][] when suggesting features, and are we
 
 
 [bug issues]: https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue+label%3Abug
+[needs design and help wanted]: https://github.com/cli/cli/issues?q=state%3Aclosed%20is%3Aissue%20label%3Aneeds-design%20label%3A%22help%20wanted%22
 [feature request issues]: https://github.com/cli/cli/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement
 [hw]: https://github.com/cli/cli/labels/help%20wanted
 [gfi]: https://github.com/cli/cli/labels/good%20first%20issue

.github/ISSUE_TEMPLATE/bug_report.md

@@ -24,3 +24,5 @@ A clear and concise description of what you expected to happen and what actually
 ### Logs
 
 Paste the activity from your command line. Redact if needed.
+
+<!-- Note: Set `GH_DEBUG=true` for verbose logs or `GH_DEBUG=api` for verbose logs with HTTP traffic details. -->

.github/ISSUE_TEMPLATE/submit-a-design-proposal.md

@@ -0,0 +1,58 @@
+---
+name: "🎨 Submit a design proposal"
+about: Submit a design to resolve an open issue that has both `needs-design` and `help-wanted` labels
+title: ''
+labels: enhancement
+assignees: ''
+
+---
+
+<!-- See [CONTRIBUTING.md](../CONTRIBUTING.md#proposing-a-design) for more information.-->
+
+### Link to issue for design submission
+
+<!-- 
+Provide a link to the issue this design is for.
+
+All design submissions must be linked to an open issue that
+has both the `needs-design` and `help-wanted` labels.
+-->
+
+### Proposed Design
+
+<!--
+Describe the design you are proposing to resolve the issue.
+
+All CLI designs must adhere to the [Primer CLI design reference](https://primer.style/cli/).
+-->
+
+### Mockup
+
+<!--
+Provide a mockup of the design you are proposing. All mockups should clearly illustrate the command(s) being run and the expected output(s). 
+
+When color and formatting are important, consider using our [CLI design Google Docs Template](https://docs.google.com/document/d/1JIRErIUuJ6fTgabiFYfCH3x91pyHuytbfa0QLnTfXKM/edit#heading=h.or54sa47ylpg).
+
+Code blocks can also be used to submit a design mockup - remember to include the command(s) being run. Example:
+
+```shell
+$ gh issue list --json title -L 5
+[
+  {
+    "title": "`gh pr checks <pr> --required` should not fail when there are no required checks"
+  },
+  {
+    "title": "gh pr view commits should include commit description"
+  },
+  {
+    "title": "Adapt the color of the device code to the color used by the terminal"
+  },
+  {
+    "title": "`gh pr create` does not default to fork when user has write access to upstream"
+  },
+  {
+    "title": "First party discussions support"
+  }
+]
+```
+-->

.github/SECURITY.md

@@ -2,7 +2,10 @@ GitHub takes the security of our software products and services seriously, inclu
 
 If you believe you have found a security vulnerability in GitHub CLI, you can report it to us in one of two ways:
 
-* Report it to this repository directly using [private vulnerability reporting][]. Such reports are not eligible for a bounty reward.
+* Report it to this repository directly using [private vulnerability reporting][].
+  * Include a description of your investigation of the GitHub CLI's codebase and why you believe an exploit is possible.
+  * POCs and links to code are greatly encouraged.
+  * Such reports are not eligible for a bounty reward.
 
 * Submit the report through [HackerOne][] to be eligible for a bounty reward.
 

.github/workflows/deployment.yml

@@ -299,7 +299,7 @@ jobs:
           rpmsign --addsign dist/*.rpm
       - name: Attest release artifacts
         if: inputs.environment == 'production'
-        uses: actions/attest-build-provenance@bdd51370e0416ac948727f861e03c2f05d32d78e # v1.3.2
+        uses: actions/attest-build-provenance@ef244123eb79f2f7a7e75d99086184180e6d0018 # v1.4.4
         with:
           subject-path: "dist/gh_*"
       - name: Run createrepo

.github/workflows/lint.yml

@@ -32,7 +32,7 @@ jobs:
           go mod verify
           go mod download
 
-          LINT_VERSION=1.54.1
+          LINT_VERSION=1.59.1
           curl -fsSL https://github.com/golangci/golangci-lint/releases/download/v${LINT_VERSION}/golangci-lint-${LINT_VERSION}-linux-amd64.tar.gz | \
             tar xz --strip-components 1 --wildcards \*/golangci-lint
           mkdir -p bin && mv golangci-lint bin/

.github/workflows/terraform.yml

@@ -0,0 +1,93 @@
+# This workflow installs the latest version of Terraform CLI and configures the Terraform CLI configuration file
+# with an API token for Terraform Cloud (app.terraform.io). On pull request events, this workflow will run
+# `terraform init`, `terraform fmt`, and `terraform plan` (speculative plan via Terraform Cloud). On push events
+# to the "trunk" branch, `terraform apply` will be executed.
+#
+# Documentation for `hashicorp/setup-terraform` is located here: https://github.com/hashicorp/setup-terraform
+#
+# To use this workflow, you will need to complete the following setup steps.
+#
+# 1. Create a `main.tf` file in the root of this repository with the `remote` backend and one or more resources defined.
+#   Example `main.tf`:
+#     # The configuration for the `remote` backend.
+#     terraform {
+#       backend "remote" {
+#         # The name of your Terraform Cloud organization.
+#         organization = "example-organization"
+#
+#         # The name of the Terraform Cloud workspace to store Terraform state files in.
+#         workspaces {
+#           name = "example-workspace"
+#         }
+#       }
+#     }
+#
+#     # An example resource that does nothing.
+#     resource "null_resource" "example" {
+#       triggers = {
+#         value = "A example resource that does nothing!"
+#       }
+#     }
+#
+#
+# 2. Generate a Terraform Cloud user API token and store it as a GitHub secret (e.g. TF_API_TOKEN) on this repository.
+#   Documentation:
+#     - https://www.terraform.io/docs/cloud/users-teams-organizations/api-tokens.html
+#     - https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets
+#
+# 3. Reference the GitHub secret in step using the `hashicorp/setup-terraform` GitHub Action.
+#   Example:
+#     - name: Setup Terraform
+#       uses: hashicorp/setup-terraform@v1
+#       with:
+#         cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}
+
+name: 'Terraform'
+
+on:
+  push:
+    branches: [ "trunk" ]
+  pull_request:
+
+permissions:
+  contents: read
+
+jobs:
+  terraform:
+    name: 'Terraform'
+    runs-on: ubuntu-latest
+    environment: production
+
+    # Use the Bash shell regardless whether the GitHub Actions runner is ubuntu-latest, macos-latest, or windows-latest
+    defaults:
+      run:
+        shell: bash
+
+    steps:
+    # Checkout the repository to the GitHub Actions runner
+    - name: Checkout
+      uses: actions/checkout@v4
+
+    # Install the latest version of Terraform CLI and configure the Terraform CLI configuration file with a Terraform Cloud user API token
+    - name: Setup Terraform
+      uses: hashicorp/setup-terraform@v1
+      with:
+        cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}
+
+    # Initialize a new or existing Terraform working directory by creating initial files, loading any remote state, downloading modules, etc.
+    - name: Terraform Init
+      run: terraform init
+
+    # Checks that all Terraform configuration files adhere to a canonical format
+    - name: Terraform Format
+      run: terraform fmt -check
+
+    # Generates an execution plan for Terraform
+    - name: Terraform Plan
+      run: terraform plan -input=false
+
+      # On push to "trunk", build or change infrastructure according to Terraform configuration files
+      # Note: It is recommended to set up a required "strict" status check in your repository for "Terraform Cloud". See the documentation on "strict" required status checks for more information: https://help.github.com/en/github/administering-a-repository/types-of-required-status-checks
+    - name: Terraform Apply
+      if: github.ref == 'refs/heads/"trunk"' && github.event_name == 'push'
+      run: terraform apply -auto-approve -input=false

.gitignore

@@ -27,4 +27,7 @@
 # vim
 *.swp
 
+# Emacs
+*~
+
 vendor/

Makefile

@@ -38,11 +38,16 @@ completions: bin/gh$(EXE)
 	bin/gh$(EXE) completion -s fish > ./share/fish/vendor_completions.d/gh.fish
 	bin/gh$(EXE) completion -s zsh > ./share/zsh/site-functions/_gh
 
-# just a convenience task around `go test`
+# just convenience tasks around `go test`
 .PHONY: test
 test:
 	go test ./...
 
+# For more information, see https://github.com/cli/cli/blob/trunk/acceptance/README.md
+.PHONY: acceptance
+acceptance:
+	go test -tags acceptance ./acceptance
+
 ## Site-related tasks are exclusively intended for use by the GitHub CLI team and for our release automation.
 
 site:

README.md

@@ -4,7 +4,7 @@
 
 ![screenshot of gh pr status](https://user-images.githubusercontent.com/98482/84171218-327e7a80-aa40-11ea-8cd1-5177fc2d0e72.png)
 
-GitHub CLI is supported for users on GitHub.com and GitHub Enterprise Server 2.20+ with support for macOS, Windows, and Linux.
+GitHub CLI is supported for users on GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server 2.20+ with support for macOS, Windows, and Linux.
 
 ## Documentation
 
@@ -60,6 +60,14 @@ Additional Conda installation options available on the [gh-feedstock page](https
 
 For more information about the Webi installer see [its homepage](https://webinstall.dev/).
 
+#### Flox
+
+| Install:          | Upgrade:                |
+| ----------------- | ----------------------- |
+| `flox install gh` | `flox upgrade toplevel` |
+
+For more information about Flox, see [its homepage](https://flox.dev)
+
 ### Linux & BSD
 
 `gh` is available via: