Remove unnecessary $ (#38339)
This commit is contained in:
@@ -76,7 +76,7 @@ You can use the `git config` command to change the email address you associate w
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. {% data reusables.user-settings.set_your_email_address_in_git %}
|
||||
```shell
|
||||
$ git config --global user.email "YOUR_EMAIL"
|
||||
git config --global user.email "YOUR_EMAIL"
|
||||
```
|
||||
3. {% data reusables.user-settings.confirm_git_email_address_correct %}
|
||||
```shell
|
||||
@@ -95,7 +95,7 @@ You can change the email address associated with commits you make in a single re
|
||||
2. Change the current working directory to the local repository where you want to configure the email address that you associate with your Git commits.
|
||||
3. {% data reusables.user-settings.set_your_email_address_in_git %}
|
||||
```shell
|
||||
$ git config user.email "YOUR_EMAIL"
|
||||
git config user.email "YOUR_EMAIL"
|
||||
```
|
||||
4. {% data reusables.user-settings.confirm_git_email_address_correct %}
|
||||
```shell
|
||||
|
||||
@@ -39,5 +39,5 @@ If you've been collaborating professionally with another person on repositories
|
||||
- Delete local copies of your forks that may exist on your computer:
|
||||
|
||||
```shell
|
||||
$ rm -rf WORK_DIRECTORY
|
||||
rm -rf WORK_DIRECTORY
|
||||
```
|
||||
|
||||
@@ -134,7 +134,7 @@ Next, the script gets the current time and sets it as an output variable that ac
|
||||
1. Optionally, to check the permission mode of the file in the git index, run the following command.
|
||||
|
||||
```shell copy
|
||||
$ git ls-files --stage entrypoint.sh
|
||||
git ls-files --stage entrypoint.sh
|
||||
```
|
||||
|
||||
An output like `100755 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 entrypoint.sh` means the file has the executable permission. In this example, `755` denotes the executable permission.
|
||||
|
||||
@@ -75,13 +75,13 @@ This procedure demonstrates how to create the service account for your GKE integ
|
||||
1. Create a new service account:
|
||||
{% raw %}
|
||||
```
|
||||
$ gcloud iam service-accounts create $SA_NAME
|
||||
gcloud iam service-accounts create $SA_NAME
|
||||
```
|
||||
{% endraw %}
|
||||
1. Retrieve the email address of the service account you just created:
|
||||
{% raw %}
|
||||
```
|
||||
$ gcloud iam service-accounts list
|
||||
gcloud iam service-accounts list
|
||||
```
|
||||
{% endraw %}
|
||||
1. Add roles to the service account. Note: Apply more restrictive roles to suit your requirements.
|
||||
@@ -101,13 +101,13 @@ This procedure demonstrates how to create the service account for your GKE integ
|
||||
1. Download the JSON keyfile for the service account:
|
||||
{% raw %}
|
||||
```
|
||||
$ gcloud iam service-accounts keys create key.json --iam-account=$SA_EMAIL
|
||||
gcloud iam service-accounts keys create key.json --iam-account=$SA_EMAIL
|
||||
```
|
||||
{% endraw %}
|
||||
1. Store the service account key as a secret named `GKE_SA_KEY`:
|
||||
{% raw %}
|
||||
```
|
||||
$ export GKE_SA_KEY=$(cat key.json | base64)
|
||||
export GKE_SA_KEY=$(cat key.json | base64)
|
||||
```
|
||||
{% endraw %}
|
||||
For more information about how to store a secret, see "[AUTOTITLE](/actions/security-guides/encrypted-secrets)."
|
||||
|
||||
@@ -129,7 +129,7 @@ actions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub
|
||||
You can use `journalctl` to monitor the real-time activity of the self-hosted runner:
|
||||
|
||||
```shell
|
||||
$ sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
|
||||
sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
|
||||
```
|
||||
|
||||
In this example output, you can see `runner01` start, receive a job named `testAction`, and then display the resulting status:
|
||||
|
||||
@@ -54,7 +54,7 @@ You can use {% data variables.product.prodname_actions_importer %} to migrate fr
|
||||
To ensure you're running the latest version of {% data variables.product.prodname_actions_importer %}, you should regularly run the `update` command:
|
||||
|
||||
```bash
|
||||
$ gh actions-importer update
|
||||
gh actions-importer update
|
||||
```
|
||||
|
||||
### Authenticating at the command line
|
||||
@@ -62,7 +62,7 @@ $ gh actions-importer update
|
||||
You must configure credentials that allow {% data variables.product.prodname_actions_importer %} to communicate with {% data variables.product.prodname_dotcom %} and your current CI server. You can configure these credentials using environment variables or a `.env.local` file. The environment variables can be configured in an interactive prompt, by running the following command:
|
||||
|
||||
```bash
|
||||
$ gh actions-importer configure
|
||||
gh actions-importer configure
|
||||
```
|
||||
|
||||
## Using the {% data variables.product.prodname_actions_importer %} CLI
|
||||
|
||||
@@ -393,7 +393,7 @@ You can use Base64 encoding to store small binary blobs as secrets. You can then
|
||||
1. Use `base64` to encode your file into a Base64 string. For example:
|
||||
|
||||
```
|
||||
$ base64 -i cert.der -o cert.base64
|
||||
base64 -i cert.der -o cert.base64
|
||||
```
|
||||
|
||||
1. Create a secret that contains the Base64 string. For example:
|
||||
|
||||
@@ -63,6 +63,6 @@ Your instance validates the hostnames for proxy exclusion using the list of IANA
|
||||
1. Enter the following command, replacing COMMA-SEPARATED-TLD-LIST with a comma-separated list of TLDs.
|
||||
|
||||
```shell
|
||||
$ ghe-config noproxy.exception-tld-list "COMMA-SEPARATED-TLD-LIST"
|
||||
ghe-config noproxy.exception-tld-list "COMMA-SEPARATED-TLD-LIST"
|
||||
```
|
||||
{% data reusables.enterprise.apply-configuration %}
|
||||
|
||||
@@ -68,11 +68,11 @@ We do not recommend customizing UFW as it can complicate some troubleshooting is
|
||||
1. Configure a custom firewall rule.
|
||||
2. Check the status of each new rule with the `status numbered` command.
|
||||
```shell
|
||||
$ sudo ufw status numbered
|
||||
sudo ufw status numbered
|
||||
```
|
||||
3. To back up your custom firewall rules, use the `cp`command to move the rules to a new file.
|
||||
```shell
|
||||
$ sudo cp -r /etc/ufw ~/ufw.backup
|
||||
sudo cp -r /etc/ufw ~/ufw.backup
|
||||
```
|
||||
|
||||
After you upgrade {% data variables.location.product_location %}, you must reapply your custom firewall rules. We recommend that you create a script to reapply your firewall custom rules.
|
||||
@@ -90,11 +90,11 @@ If something goes wrong after you change the firewall rules, you can reset the r
|
||||
{% data reusables.enterprise_installation.ssh-into-instance %}
|
||||
2. To restore the previous backup rules, copy them back to the firewall with the `cp` command.
|
||||
```shell
|
||||
$ sudo cp -f ~/ufw.backup/*rules /etc/ufw
|
||||
sudo cp -f ~/ufw.backup/*rules /etc/ufw
|
||||
```
|
||||
3. Restart the firewall with the `systemctl` command.
|
||||
```shell
|
||||
$ sudo systemctl restart ufw
|
||||
sudo systemctl restart ufw
|
||||
```
|
||||
4. Confirm that the rules are back to their defaults with the `ufw status` command.
|
||||
```shell
|
||||
|
||||
@@ -117,7 +117,7 @@ $ ghe-config -l
|
||||
Allows you to find the universally unique identifier (UUID) of your node in `cluster.conf`.
|
||||
|
||||
```shell
|
||||
$ ghe-config HOSTNAME.uuid
|
||||
ghe-config HOSTNAME.uuid
|
||||
```
|
||||
|
||||
Allows you to exempt a list of users from REST API rate limits. A hard limit of 120,000 requests will still apply to these users. Usernames you provide for this command are case-sensitive. For more information, see "[AUTOTITLE](/rest/overview/resources-in-the-rest-api#rate-limiting)."
|
||||
@@ -278,7 +278,7 @@ ghe-org-admin-promote -a
|
||||
Use this command to immediately unlock the {% data variables.enterprise.management_console %} after {% ifversion enterprise-authentication-rate-limits %}an account lockout. To configure authentication policies for {% data variables.location.product_location %}, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/configuring-rate-limits#configuring-authentication-policy-rate-limits)".{% else %}10 failed login attempts in the span of 10 minutes.{% endif %}
|
||||
|
||||
```shell
|
||||
$ ghe-reactivate-admin-login
|
||||
ghe-reactivate-admin-login
|
||||
```
|
||||
|
||||
### ghe-saml-mapping-csv
|
||||
@@ -410,7 +410,7 @@ This utility allows you to configure the primary network interface.
|
||||
To enter visual mode, which will guide you through configuration of network settings:
|
||||
|
||||
```shell
|
||||
$ ghe-setup-network -v
|
||||
ghe-setup-network -v
|
||||
```
|
||||
|
||||
Use the -h flag for additional options.
|
||||
@@ -420,7 +420,7 @@ Use the -h flag for additional options.
|
||||
This utility checks the existing SSH host keys against the list of known leaked SSH host keys.
|
||||
|
||||
```shell
|
||||
$ ghe-ssh-check-host-keys
|
||||
ghe-ssh-check-host-keys
|
||||
```
|
||||
|
||||
If a leaked host key is found the utility exits with status `1` and a message:
|
||||
@@ -540,7 +540,7 @@ ghe-ssl-generate-csr
|
||||
Some platforms require this script to expand the user volume. For more information, see "[AUTOTITLE](/admin/enterprise-management/updating-the-virtual-machine-and-physical-resources/increasing-storage-capacity)".
|
||||
|
||||
```shell
|
||||
$ ghe-storage-extend
|
||||
ghe-storage-extend
|
||||
```
|
||||
|
||||
### ghe-version
|
||||
@@ -548,7 +548,7 @@ $ ghe-storage-extend
|
||||
This utility prints the version, platform, and build of {% data variables.location.product_location %}.
|
||||
|
||||
```shell
|
||||
$ ghe-version
|
||||
ghe-version
|
||||
```
|
||||
|
||||
### ghe-webhook-logs
|
||||
@@ -583,19 +583,19 @@ This utility allows you to enforce an even distribution of allocations across yo
|
||||
To output a list of balanceable jobs and their associated allocation spread:
|
||||
|
||||
```shell
|
||||
$ ghe-cluster-balance status
|
||||
ghe-cluster-balance status
|
||||
```
|
||||
|
||||
To output allocation counts for a given job or comma-delimited list of jobs:
|
||||
|
||||
```shell
|
||||
$ ghe-cluster-balance -j JOB
|
||||
ghe-cluster-balance -j JOB
|
||||
```
|
||||
|
||||
To rebalance problematic allocations for a given job or comma-delimited list of jobs:
|
||||
|
||||
```shell
|
||||
$ ghe-cluster-balance rebalance -j JOB
|
||||
ghe-cluster-balance rebalance -j JOB
|
||||
```
|
||||
|
||||
You can use the following flags with `ghe-cluster-balance rebalance`.
|
||||
@@ -611,13 +611,13 @@ Flag | Description
|
||||
To output completion scripts for the given shell:
|
||||
|
||||
```shell
|
||||
$ ghe-cluster-balance completion
|
||||
ghe-cluster-balance completion
|
||||
```
|
||||
|
||||
To display a short description of the utility and any valid subcommands:
|
||||
|
||||
```shell
|
||||
$ ghe-cluster-balance help
|
||||
ghe-cluster-balance help
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
@@ -627,7 +627,7 @@ $ ghe-cluster-balance help
|
||||
Check the health of your nodes and services in a cluster deployment of {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
```shell
|
||||
$ ghe-cluster-status
|
||||
ghe-cluster-status
|
||||
```
|
||||
|
||||
### ghe-cluster-support-bundle
|
||||
@@ -640,38 +640,38 @@ By default, the command creates the tarball in _/tmp_, but you can also have it
|
||||
|
||||
To create a standard bundle:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -o' > cluster-support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -o' > cluster-support-bundle.tgz
|
||||
```
|
||||
|
||||
To create a standard bundle including data from the last 3 hours:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- "ghe-cluster-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}3hours {% elsif ghes < 3.9 %}'3 hours' {% endif %} -o" > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- "ghe-cluster-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}3hours {% elsif ghes < 3.9 %}'3 hours' {% endif %} -o" > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create a standard bundle including data from the last 2 days:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- "ghe-cluster-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}2days {% elsif ghes < 3.9 %}'2 days' {% endif %} -o" > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- "ghe-cluster-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}2days {% elsif ghes < 3.9 %}'2 days' {% endif %} -o" > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create a standard bundle including data from the last 4 days and 8 hours:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- "ghe-cluster-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}4days8hours {% elsif ghes < 3.9 %}'4 days 8 hours' {% endif %} -o" > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- "ghe-cluster-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}4days8hours {% elsif ghes < 3.9 %}'4 days 8 hours' {% endif %} -o" > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create an extended bundle including data from the last 8 days:
|
||||
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- ghe-cluster-support-bundle -x -o' > cluster-support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- ghe-cluster-support-bundle -x -o' > cluster-support-bundle.tgz
|
||||
```
|
||||
|
||||
To send a bundle to {% data variables.contact.github_support %}:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -u'
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -u'
|
||||
```
|
||||
|
||||
To send a bundle to {% data variables.contact.github_support %} and associate the bundle with a ticket:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -t TICKET_ID'
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-cluster-support-bundle -t TICKET_ID'
|
||||
```
|
||||
|
||||
### ghe-dpages
|
||||
@@ -1048,38 +1048,38 @@ By default, the command creates the tarball in _/tmp_, but you can also have it
|
||||
|
||||
To create a standard bundle:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -o' > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -o' > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create a standard bundle including data from the last 3 hours:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- "ghe-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}3hours {% elsif ghes < 3.9 %}'3 hours' {% endif %} -o" > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- "ghe-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}3hours {% elsif ghes < 3.9 %}'3 hours' {% endif %} -o" > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create a standard bundle including data from the last 2 days:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- "ghe-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}2days {% elsif ghes < 3.9 %}'2 days' {% endif %} -o" > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- "ghe-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}2days {% elsif ghes < 3.9 %}'2 days' {% endif %} -o" > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create a standard bundle including data from the last 4 days and 8 hours:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- "ghe-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}4days8hours {% elsif ghes < 3.9 %}'4 days 8 hours' {% endif %} -o" > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- "ghe-support-bundle -p {% ifversion bundle-cli-syntax-no-quotes %}4days8hours {% elsif ghes < 3.9 %}'4 days 8 hours' {% endif %} -o" > support-bundle.tgz
|
||||
```
|
||||
|
||||
To create an extended bundle including data from the last 8 days:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -x -o' > support-bundle.tgz
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -x -o' > support-bundle.tgz
|
||||
```
|
||||
|
||||
To send a bundle to {% data variables.contact.github_support %}:
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -u'
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -u'
|
||||
```
|
||||
|
||||
To send a bundle to {% data variables.contact.github_support %} and associate the bundle with a ticket:
|
||||
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -t TICKET_ID'
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-support-bundle -t TICKET_ID'
|
||||
```
|
||||
|
||||
### ghe-support-upload
|
||||
@@ -1135,7 +1135,7 @@ A file containing the status of the download is available at _/var/lib/ghe-updat
|
||||
To check for the latest {% data variables.product.prodname_enterprise %} release, use the `-i` switch.
|
||||
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME -- 'ghe-update-check'
|
||||
ssh -p 122 admin@HOSTNAME -- 'ghe-update-check'
|
||||
```
|
||||
|
||||
### ghe-upgrade
|
||||
@@ -1162,7 +1162,7 @@ The `ghe-upgrade-scheduler` utility is best suited for scheduling hotpatch upgra
|
||||
|
||||
To schedule a new installation for a package:
|
||||
```shell
|
||||
$ ghe-upgrade-scheduler -c "0 2 15 12 *" UPGRADE-PACKAGE-FILENAME
|
||||
ghe-upgrade-scheduler -c "0 2 15 12 *" UPGRADE-PACKAGE-FILENAME
|
||||
```
|
||||
|
||||
To show scheduled installations for a package:
|
||||
@@ -1173,7 +1173,7 @@ $ ghe-upgrade-scheduler -s UPGRADE PACKAGE FILENAME
|
||||
|
||||
To remove scheduled installations for a package:
|
||||
```shell
|
||||
$ ghe-upgrade-scheduler -r UPGRADE PACKAGE FILENAME
|
||||
ghe-upgrade-scheduler -r UPGRADE PACKAGE FILENAME
|
||||
```
|
||||
|
||||
## User management
|
||||
|
||||
@@ -71,7 +71,7 @@ Backup snapshots are written to the disk path set by the `GHE_DATA_DIR` data dir
|
||||
1. To clone the [{% data variables.product.prodname_enterprise_backup_utilities %} project repository](https://github.com/github/backup-utils/) to a local directory on your backup host, run the following command.
|
||||
|
||||
```
|
||||
$ git clone https://github.com/github/backup-utils.git /path/to/target/directory/backup-utils
|
||||
git clone https://github.com/github/backup-utils.git /path/to/target/directory/backup-utils
|
||||
```
|
||||
1. To change into the local repository directory, run the following command.
|
||||
|
||||
@@ -159,7 +159,7 @@ If your backup host has internet connectivity and you previously used a compress
|
||||
1. To back up your existing {% data variables.product.prodname_enterprise_backup_utilities %} configuration, copy your current `backup.config` file to a safe location, such as your home directory.
|
||||
|
||||
```
|
||||
$ cp backup.config $HOME/backup.config.saved-$(date +%Y%m%d-%H%M%S)
|
||||
cp backup.config $HOME/backup.config.saved-$(date +%Y%m%d-%H%M%S)
|
||||
```
|
||||
|
||||
1. Change to the local directory on your backup host where you want to install the {% data variables.product.prodname_enterprise_backup_utilities %} Git repository.
|
||||
@@ -177,7 +177,7 @@ If your backup host has internet connectivity and you previously used a compress
|
||||
1. To restore your backup configuration from earlier, copy your existing backup configuration file to the local repository directory. Replace the path in the command with the location of the file saved in step 2.
|
||||
|
||||
```
|
||||
$ cp PATH/TO/BACKUP/FROM/STEP/2 backup.config
|
||||
cp PATH/TO/BACKUP/FROM/STEP/2 backup.config
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -44,5 +44,5 @@ The NTP protocol continuously corrects small time synchronization discrepancies.
|
||||
- Use the `chronyc` command to synchronize the server with the configured NTP server. For example:
|
||||
|
||||
```shell
|
||||
$ sudo chronyc -a makestep
|
||||
sudo chronyc -a makestep
|
||||
```
|
||||
|
||||
@@ -26,11 +26,11 @@ If you have a Linux machine with OpenSSL installed, you can remove your passphra
|
||||
|
||||
1. Rename your original key file.
|
||||
```shell
|
||||
$ mv yourdomain.key yourdomain.key.orig
|
||||
mv yourdomain.key yourdomain.key.orig
|
||||
```
|
||||
2. Generate a new key without a passphrase.
|
||||
```shell
|
||||
$ openssl rsa -in yourdomain.key.orig -out yourdomain.key
|
||||
openssl rsa -in yourdomain.key.orig -out yourdomain.key
|
||||
```
|
||||
|
||||
You'll be prompted for the key's passphrase when you run this command.
|
||||
@@ -42,7 +42,7 @@ For more information about OpenSSL, see [OpenSSL's documentation](https://www.op
|
||||
If you have OpenSSL installed, you can convert your key into PEM format by using the `openssl` command. For example, you can convert a key from DER format into PEM format.
|
||||
|
||||
```shell
|
||||
$ openssl rsa -in yourdomain.der -inform DER -out yourdomain.key -outform PEM
|
||||
openssl rsa -in yourdomain.der -inform DER -out yourdomain.key -outform PEM
|
||||
```
|
||||
|
||||
Otherwise, you can use the SSL Converter tool to convert your certificate into the PEM format. For more information, see the [SSL Converter tool's documentation](https://www.sslshopper.com/ssl-converter.html).
|
||||
@@ -58,7 +58,7 @@ Clients such as web browsers and command-line Git will display an error message
|
||||
If you are using a certificate signed by a certificate authority (CA), the certificate file that you upload to {% data variables.product.prodname_ghe_server %} must include a certificate chain with that CA's root certificate. To create such a file, concatenate your entire certificate chain (or "certificate bundle") onto the end of your certificate, ensuring that the principal certificate with your hostname comes first. On most systems you can do this with a command similar to:
|
||||
|
||||
```shell
|
||||
$ cat yourdomain.com.crt bundle-certificates.crt > yourdomain.combined.crt
|
||||
cat yourdomain.com.crt bundle-certificates.crt > yourdomain.combined.crt
|
||||
```
|
||||
|
||||
You should be able to download a certificate bundle (for example, `bundle-certificates.crt`) from your certificate authority or TLS vendor.
|
||||
@@ -70,15 +70,15 @@ If your {% data variables.product.prodname_ghe_server %} appliance interacts wit
|
||||
1. Obtain the CA's root certificate from your local certificate authority and ensure it is in PEM format.
|
||||
2. Copy the file to your {% data variables.product.prodname_ghe_server %} appliance over SSH as the "admin" user on port 122.
|
||||
```shell
|
||||
$ scp -P 122 rootCA.crt admin@HOSTNAME:/home/admin
|
||||
scp -P 122 rootCA.crt admin@HOSTNAME:/home/admin
|
||||
```
|
||||
3. Connect to the {% data variables.product.prodname_ghe_server %} administrative shell over SSH as the "admin" user on port 122.
|
||||
```shell
|
||||
$ ssh -p 122 admin@HOSTNAME
|
||||
ssh -p 122 admin@HOSTNAME
|
||||
```
|
||||
4. Import the certificate into the system-wide certificate store.
|
||||
```shell
|
||||
$ ghe-ssl-ca-certificate-install -c rootCA.crt
|
||||
ghe-ssl-ca-certificate-install -c rootCA.crt
|
||||
```
|
||||
|
||||
## Updating a TLS certificate
|
||||
|
||||
@@ -38,7 +38,7 @@ Then, when told to fetch `https://github.example.com/myorg/myrepo`, Git will ins
|
||||
1. Connect to the repository cache's IP address using SSH.
|
||||
|
||||
```shell
|
||||
$ ssh -p 122 admin@REPLICA-IP
|
||||
ssh -p 122 admin@REPLICA-IP
|
||||
```
|
||||
|
||||
{% data reusables.enterprise_installation.generate-replication-key-pair %}
|
||||
@@ -46,22 +46,22 @@ Then, when told to fetch `https://github.example.com/myorg/myrepo`, Git will ins
|
||||
1. To verify the connection to the primary and enable replica mode for the repository cache, run `ghe-repl-setup` again.
|
||||
- If the repository cache is your only additional node, no arguments are required.
|
||||
```shell
|
||||
$ ghe-repl-setup PRIMARY-IP
|
||||
ghe-repl-setup PRIMARY-IP
|
||||
```
|
||||
- If you're configuring a repository cache in addition to one or more existing replicas, use the `-a` or `--add` argument.
|
||||
```
|
||||
$ ghe-repl-setup -a PRIMARY-IP
|
||||
ghe-repl-setup -a PRIMARY-IP
|
||||
```
|
||||
{% ifversion ghes < 3.6 %}
|
||||
1. If you haven't already, set the datacenter name on the primary and any replica appliances, replacing DC-NAME with a datacenter name.
|
||||
|
||||
```
|
||||
$ ghe-repl-node --datacenter DC-NAME
|
||||
ghe-repl-node --datacenter DC-NAME
|
||||
```
|
||||
1. Set a `cache-location` for the repository cache, replacing _CACHE-LOCATION_ with an alphanumeric identifier, such as the region where the cache is deployed. Also set a datacenter name for this cache; new caches will attempt to seed from another cache in the same datacenter.
|
||||
|
||||
```shell
|
||||
$ ghe-repl-node --cache CACHE-LOCATION --datacenter REPLICA-DC-NAME
|
||||
ghe-repl-node --cache CACHE-LOCATION --datacenter REPLICA-DC-NAME
|
||||
```
|
||||
{% else %}
|
||||
1. To configure the repository cache, use the `ghe-repl-node` command and include the necessary parameters.
|
||||
@@ -70,12 +70,12 @@ Then, when told to fetch `https://github.example.com/myorg/myrepo`, Git will ins
|
||||
- If you haven't already, set the datacenter name on the primary and any replica appliances, replacing DC-NAME with a datacenter name.
|
||||
|
||||
```
|
||||
$ ghe-repl-node --datacenter DC-NAME
|
||||
ghe-repl-node --datacenter DC-NAME
|
||||
```
|
||||
- New caches will attempt to seed from another cache in the same datacenter. Set a `datacenter` for the repository cache, replacing _REPLICA-DC-NAME_ with the name of the datacenter where you're deploying the node.
|
||||
|
||||
```shell
|
||||
$ ghe-repl-node --cache CACHE-LOCATION --cache-domain EXTERNAL-CACHE-DOMAIN --datacenter REPLICA-DC-NAME
|
||||
ghe-repl-node --cache CACHE-LOCATION --cache-domain EXTERNAL-CACHE-DOMAIN --datacenter REPLICA-DC-NAME
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
@@ -98,19 +98,19 @@ Data location policies affect only Git content. Content in the database, such as
|
||||
You can configure a policy to replicate all networks with the `--default` flag. For example, this command will create a policy to replicate a single copy of every repository network to the set of repository caches whose `cache_location` is "kansas".
|
||||
|
||||
```
|
||||
$ ghe-spokesctl cache-policy set --default 1 kansas
|
||||
ghe-spokesctl cache-policy set --default 1 kansas
|
||||
```
|
||||
|
||||
To configure replication for a repository network, specify the repository that is the root of the network. A repository network includes a repository and all of the repository's forks. You cannot replicate part of a network without replicating the whole network.
|
||||
|
||||
```
|
||||
$ ghe-spokesctl cache-policy set <owner/repository> 1 kansas
|
||||
ghe-spokesctl cache-policy set <owner/repository> 1 kansas
|
||||
```
|
||||
|
||||
You can override a policy that replicates all networks and exclude specific networks by specifying a replica count of zero for the network. For example, this command specifies that any repository cache in location "kansas" cannot contain any copies of that network.
|
||||
|
||||
```
|
||||
$ ghe-spokesctl cache-policy set <owner/repository> 0 kansas
|
||||
ghe-spokesctl cache-policy set <owner/repository> 0 kansas
|
||||
```
|
||||
|
||||
Replica counts greater than one in a given cache location are not supported.
|
||||
|
||||
@@ -113,7 +113,7 @@ We strongly recommend enabling PROXY support for both your instance and the load
|
||||
|
||||
- For your instance, use this command:
|
||||
```shell
|
||||
$ ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
|
||||
ghe-config 'loadbalancer.proxy-protocol' 'true' && ghe-cluster-config-apply
|
||||
```
|
||||
- For the load balancer, use the instructions provided by your vendor.
|
||||
|
||||
@@ -126,7 +126,7 @@ We strongly recommend enabling PROXY support for both your instance and the load
|
||||
To enable the `X-Forwarded-For` header, use this command:
|
||||
|
||||
```shell
|
||||
$ ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
|
||||
ghe-config 'loadbalancer.http-forward' 'true' && ghe-cluster-config-apply
|
||||
```
|
||||
|
||||
{% data reusables.enterprise_clustering.without_proxy_protocol_ports %}
|
||||
|
||||
@@ -26,7 +26,7 @@ topics:
|
||||
1. Back up your data with [{% data variables.product.prodname_enterprise_backup_utilities %}](https://github.com/github/backup-utils#readme).
|
||||
2. From the administrative shell of any node, use the `ghe-cluster-hotpatch` command to install the latest hotpatch. You can provide a URL for a hotpatch, or manually download the hotpatch and specify a local filename.
|
||||
```shell
|
||||
$ ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg
|
||||
ghe-cluster-hotpatch https://HOTPATCH-URL/FILENAME.hpkg
|
||||
```
|
||||
|
||||
## Upgrading with an upgrade package
|
||||
|
||||
@@ -24,13 +24,13 @@ shortTitle: Create HA replica
|
||||
{% data reusables.enterprise_installation.replica-steps %}
|
||||
1. Connect to the replica appliance's IP address using SSH.
|
||||
```shell
|
||||
$ ssh -p 122 admin@REPLICA_IP
|
||||
ssh -p 122 admin@REPLICA_IP
|
||||
```
|
||||
{% data reusables.enterprise_installation.generate-replication-key-pair %}
|
||||
{% data reusables.enterprise_installation.add-ssh-key-to-primary %}
|
||||
1. To verify the connection to the primary and enable replica mode for the new replica, run `ghe-repl-setup` again.
|
||||
```shell
|
||||
$ ghe-repl-setup PRIMARY_IP
|
||||
ghe-repl-setup PRIMARY_IP
|
||||
```
|
||||
{% data reusables.enterprise_installation.replication-command %}
|
||||
{% data reusables.enterprise_installation.verify-replication-channel %}
|
||||
|
||||
@@ -26,7 +26,7 @@ The time required to failover depends on how long it takes to manually promote t
|
||||
|
||||
- You can also use the `ghe-maintenance -s` command.
|
||||
```shell
|
||||
$ ghe-maintenance -s
|
||||
ghe-maintenance -s
|
||||
```
|
||||
|
||||
- When the number of active Git operations, MySQL queries, and Resque jobs reaches zero, wait 30 seconds.
|
||||
@@ -40,12 +40,12 @@ The time required to failover depends on how long it takes to manually promote t
|
||||
- To verify all replication channels report `OK`, use the `ghe-repl-status -vv` command.
|
||||
|
||||
```shell
|
||||
$ ghe-repl-status -vv
|
||||
ghe-repl-status -vv
|
||||
```
|
||||
|
||||
4. On the replica appliance, to stop replication and promote the replica appliance to primary status, use the `ghe-repl-promote` command. This will also automatically put the primary node in maintenance mode if it’s reachable.
|
||||
```shell
|
||||
$ ghe-repl-promote
|
||||
ghe-repl-promote
|
||||
```
|
||||
|
||||
{% note %}
|
||||
@@ -60,11 +60,11 @@ The time required to failover depends on how long it takes to manually promote t
|
||||
8. Appliances you do not intend to setup replication to that were part of the high availability configuration prior the failover, need to be removed from the high availability configuration by UUID.
|
||||
- On the former appliances, get their UUID via `cat /data/user/common/uuid`.
|
||||
```shell
|
||||
$ cat /data/user/common/uuid
|
||||
cat /data/user/common/uuid
|
||||
```
|
||||
- On the new primary, remove the UUIDs using `ghe-repl-teardown`. Please replace *`UUID`* with a UUID you retrieved in the previous step.
|
||||
```shell
|
||||
$ ghe-repl-teardown -u UUID
|
||||
ghe-repl-teardown -u UUID
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -29,16 +29,16 @@ You can use the former primary appliance as the new replica appliance if the fai
|
||||
|
||||
1. Connect to the former primary appliance's IP address using SSH.
|
||||
```shell
|
||||
$ ssh -p 122 admin@ FORMER_PRIMARY_IP
|
||||
ssh -p 122 admin@ FORMER_PRIMARY_IP
|
||||
```
|
||||
1. Enable maintenance mode on the former primary appliance. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)."
|
||||
1. On the former primary appliance, run `ghe-repl-setup` with the IP address of the former replica.
|
||||
```shell
|
||||
$ ghe-repl-setup FORMER_REPLICA_IP
|
||||
ghe-repl-setup FORMER_REPLICA_IP
|
||||
```
|
||||
{% data reusables.enterprise_installation.add-ssh-key-to-primary %}
|
||||
1. To verify the connection to the new primary and enable replica mode for the new replica, run `ghe-repl-setup` again.
|
||||
```shell
|
||||
$ ghe-repl-setup FORMER_REPLICA_IP
|
||||
ghe-repl-setup FORMER_REPLICA_IP
|
||||
```
|
||||
{% data reusables.enterprise_installation.replication-command %}
|
||||
|
||||
@@ -20,11 +20,11 @@ shortTitle: Remove a HA replica
|
||||
1. If necessary, stop a geo-replication replica from serving user traffic by removing the Geo DNS entries for the replica.
|
||||
2. On the replica where you wish to temporarily stop replication, run ghe-repl-stop.
|
||||
```shell
|
||||
$ ghe-repl-stop
|
||||
ghe-repl-stop
|
||||
```
|
||||
3. To start replication again, run `ghe-repl-start`.
|
||||
```shell
|
||||
$ ghe-repl-start
|
||||
ghe-repl-start
|
||||
```
|
||||
|
||||
## Removing replication permanently
|
||||
@@ -32,11 +32,11 @@ shortTitle: Remove a HA replica
|
||||
1. If necessary, stop a geo-replication replica from serving user traffic by removing the Geo DNS entries for the replica.
|
||||
2. On the replica you wish to remove replication from, run `ghe-repl-stop`.
|
||||
```shell
|
||||
$ ghe-repl-stop
|
||||
ghe-repl-stop
|
||||
```
|
||||
3. On the replica, to tear down the replication state, run `ghe-repl-teardown`.
|
||||
```shell
|
||||
$ ghe-repl-teardown
|
||||
ghe-repl-teardown
|
||||
```
|
||||
|
||||
{% ifversion ghes %}
|
||||
|
||||
@@ -38,11 +38,11 @@ As more users join {% data variables.location.product_location %}, you may need
|
||||
3. Put the appliance in maintenance mode. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)."
|
||||
4. Reboot the appliance to detect the new storage allocation:
|
||||
```shell
|
||||
$ sudo reboot
|
||||
sudo reboot
|
||||
```
|
||||
5. Run the `ghe-storage-extend` command to expand the `/data/user` filesystem:
|
||||
```shell
|
||||
$ ghe-storage-extend
|
||||
ghe-storage-extend
|
||||
```
|
||||
6. Ensure system services are functioning correctly, then release maintenance mode. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/enabling-and-scheduling-maintenance-mode)."
|
||||
|
||||
@@ -51,7 +51,7 @@ As more users join {% data variables.location.product_location %}, you may need
|
||||
1. Set up a new {% data variables.product.prodname_ghe_server %} instance with a larger root disk using the same version as your current appliance. For more information, see "[AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance)."
|
||||
2. Shut down the current appliance:
|
||||
```shell
|
||||
$ sudo poweroff
|
||||
sudo poweroff
|
||||
```
|
||||
3. Detach the data disk from the current appliance using your virtualization platform's tools.
|
||||
4. Attach the data disk to the new appliance with the larger root disk.
|
||||
@@ -68,24 +68,24 @@ As more users join {% data variables.location.product_location %}, you may need
|
||||
1. Run the `lsblk` command to identify the new disk's device name.
|
||||
1. Run the `parted` command to format the disk, substituting your device name for `/dev/xvdg`:
|
||||
```shell
|
||||
$ sudo parted /dev/xvdg mklabel msdos
|
||||
$ sudo parted /dev/xvdg mkpart primary ext4 0% 50%
|
||||
$ sudo parted /dev/xvdg mkpart primary ext4 50% 100%
|
||||
sudo parted /dev/xvdg mklabel msdos
|
||||
sudo parted /dev/xvdg mkpart primary ext4 0% 50%
|
||||
sudo parted /dev/xvdg mkpart primary ext4 50% 100%
|
||||
```
|
||||
1. If your appliance is configured for high-availability or geo-replication, to stop replication run the `ghe-repl-stop` command on each replica node:
|
||||
|
||||
```shell
|
||||
$ ghe-repl-stop
|
||||
ghe-repl-stop
|
||||
```
|
||||
|
||||
1. To install the {% data variables.product.prodname_ghe_server %} software on the newly partitioned disk, run the `ghe-upgrade` command. You must replace **PACKAGE-NAME.pkg** with the path to a platform-specific upgrade package that matches the version of {% data variables.product.prodname_ghe_server %} already running on the appliance. You cannot use a universal hotpatch upgrade package, such as `github-enterprise-2.11.9.hpkg`. After the `ghe-upgrade` command completes, application services will automatically terminate.
|
||||
|
||||
```shell
|
||||
$ ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg1
|
||||
ghe-upgrade PACKAGE-NAME.pkg -s -t /dev/xvdg1
|
||||
```
|
||||
1. Shut down the appliance:
|
||||
```shell
|
||||
$ sudo poweroff
|
||||
sudo poweroff
|
||||
```
|
||||
1. In the hypervisor, remove the old root disk and attach the new root disk at the same location as the old root disk.
|
||||
1. Start the appliance.
|
||||
|
||||
@@ -29,7 +29,7 @@ To restore a backup of {% data variables.location.product_location %} with {% da
|
||||
1. SSH into the destination instance. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)."
|
||||
|
||||
```shell copy
|
||||
$ ssh -p 122 admin@HOSTNAME
|
||||
ssh -p 122 admin@HOSTNAME
|
||||
```
|
||||
1. Configure the destination instance to use the same external storage service for {% data variables.product.prodname_actions %} as the source instance by entering one of the following commands.
|
||||
{% indented_data_reference reusables.actions.configure-storage-provider-platform-commands spaces=3 %}
|
||||
|
||||
@@ -176,11 +176,11 @@ There are three ways to resolve this problem:
|
||||
1. Log in to the administrative shell using SSH. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)."
|
||||
1. To remove the limitations on workflows triggered by {% data variables.product.prodname_dependabot %} on {% data variables.location.product_location %}, use the following command.
|
||||
``` shell
|
||||
$ ghe-config app.actions.disable-dependabot-enforcement true
|
||||
ghe-config app.actions.disable-dependabot-enforcement true
|
||||
```
|
||||
1. Apply the configuration.
|
||||
```shell
|
||||
$ ghe-config-apply
|
||||
ghe-config-apply
|
||||
```
|
||||
1. Return to {% data variables.product.prodname_ghe_server %}.
|
||||
|
||||
@@ -205,19 +205,19 @@ To install the official bundled actions and starter workflows within a designate
|
||||
1. Log in to the administrative shell using SSH. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)."
|
||||
1. To designate your organization as the location to store the bundled actions, use the `ghe-config` command, replacing `ORGANIZATION` with the name of your organization.
|
||||
```shell
|
||||
$ ghe-config app.actions.actions-org ORGANIZATION
|
||||
ghe-config app.actions.actions-org ORGANIZATION
|
||||
```
|
||||
and:
|
||||
```shell
|
||||
$ ghe-config app.actions.github-org ORGANIZATION
|
||||
ghe-config app.actions.github-org ORGANIZATION
|
||||
```
|
||||
1. To add the bundled actions to your organization, unset the SHA.
|
||||
```shell
|
||||
$ ghe-config --unset 'app.actions.actions-repos-sha1sum'
|
||||
ghe-config --unset 'app.actions.actions-repos-sha1sum'
|
||||
```
|
||||
1. Apply the configuration.
|
||||
```shell
|
||||
$ ghe-config-apply
|
||||
ghe-config-apply
|
||||
```
|
||||
|
||||
After you've completed these steps, you can resume configuring {% data variables.product.prodname_actions %} at "[AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/getting-started-with-github-actions-for-github-enterprise-server#managing-access-permissions-for-github-actions-in-your-enterprise)."
|
||||
|
||||
@@ -49,7 +49,7 @@ You can configure {% data variables.product.product_name %} to write verbose deb
|
||||
Some output in {% ifversion opentelemetry-and-otel-log-migration-phase-1 %}_/var/log/github/unicorn.log_ or _/var/log/github/resqued.log_{% elsif ghes < 3.9 %}_/var/log/github/auth.log_{% endif %} may be Base64-encoded. You can access the administrative shell and use the `base64` utility on {% data variables.location.product_location %} to decode these responses. For more information, see "[AUTOTITLE](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh)."
|
||||
|
||||
```shell
|
||||
$ base64 --decode ENCODED_OUTPUT
|
||||
base64 --decode ENCODED_OUTPUT
|
||||
```
|
||||
|
||||
## Error: "Another user already owns the account"
|
||||
|
||||
@@ -82,14 +82,14 @@ If you're setting up your AMI for the first time, you will need to create a secu
|
||||
|
||||
1. Using the AWS CLI, create a new security group. For more information, see "[create-security-group](https://docs.aws.amazon.com/cli/latest/reference/ec2/create-security-group.html)" in the AWS documentation.
|
||||
```shell
|
||||
$ aws ec2 create-security-group --group-name SECURITY_GROUP_NAME --description "SECURITY GROUP DESCRIPTION"
|
||||
aws ec2 create-security-group --group-name SECURITY_GROUP_NAME --description "SECURITY GROUP DESCRIPTION"
|
||||
```
|
||||
|
||||
2. Take note of the security group ID (`sg-xxxxxxxx`) of your newly created security group.
|
||||
|
||||
3. Create a security group rule for each of the ports in the table below. For more information, see "[authorize-security-group-ingress](https://docs.aws.amazon.com/cli/latest/reference/ec2/authorize-security-group-ingress.html)" in the AWS documentation.
|
||||
```shell
|
||||
$ aws ec2 authorize-security-group-ingress --group-id SECURITY_GROUP_ID --protocol PROTOCOL --port PORT_NUMBER --cidr SOURCE IP RANGE
|
||||
aws ec2 authorize-security-group-ingress --group-id SECURITY_GROUP_ID --protocol PROTOCOL --port PORT_NUMBER --cidr SOURCE IP RANGE
|
||||
```
|
||||
This table identifies what each port is used for.
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ Before launching {% data variables.location.product_location %} on Azure, you'll
|
||||
|
||||
1. Find the most recent {% data variables.product.prodname_ghe_server %} appliance image. For more information about the `vm image list` command, see "[`az vm image list`](https://docs.microsoft.com/cli/azure/vm/image?view=azure-cli-latest#az_vm_image_list)" in the Microsoft documentation.
|
||||
```shell
|
||||
$ az vm image list --all -f GitHub-Enterprise | grep '"urn":' | sort -V
|
||||
az vm image list --all -f GitHub-Enterprise | grep '"urn":' | sort -V
|
||||
```
|
||||
|
||||
2. Create a new VM using the appliance image you found. For more information, see "[`az vm create`](https://docs.microsoft.com/cli/azure/vm?view=azure-cli-latest#az_vm_create)" in the Microsoft documentation.
|
||||
@@ -49,13 +49,13 @@ Before launching {% data variables.location.product_location %} on Azure, you'll
|
||||
Pass in options for the name of your VM, the resource group, the size of your VM, the name of your preferred Azure region, the name of the appliance image VM you listed in the previous step, and the storage SKU for premium storage. For more information about resource groups, see "[Resource groups](https://docs.microsoft.com/azure/azure-resource-manager/resource-group-overview#resource-groups)" in the Microsoft documentation.
|
||||
|
||||
```shell
|
||||
$ az vm create -n VM_NAME -g RESOURCE_GROUP --size VM_SIZE -l REGION --image APPLIANCE_IMAGE_NAME --storage-sku Premium_LRS
|
||||
az vm create -n VM_NAME -g RESOURCE_GROUP --size VM_SIZE -l REGION --image APPLIANCE_IMAGE_NAME --storage-sku Premium_LRS
|
||||
```
|
||||
|
||||
3. Configure the security settings on your VM to open up required ports. For more information, see "[`az vm open-port`](https://docs.microsoft.com/cli/azure/vm?view=azure-cli-latest#az_vm_open_port)" in the Microsoft documentation. See the table below for a description of each port to determine what ports you need to open.
|
||||
|
||||
```shell
|
||||
$ az vm open-port -n VM_NAME -g RESOURCE_GROUP --port PORT_NUMBER
|
||||
az vm open-port -n VM_NAME -g RESOURCE_GROUP --port PORT_NUMBER
|
||||
```
|
||||
|
||||
This table identifies what each port is used for.
|
||||
@@ -67,7 +67,7 @@ Before launching {% data variables.location.product_location %} on Azure, you'll
|
||||
Pass in options for the name of your VM (for example, `ghe-acme-corp`), the resource group, the premium storage SKU, the size of the disk (for example, `200`), and a name for the resulting VHD.
|
||||
|
||||
```shell
|
||||
$ az vm disk attach --vm-name VM_NAME -g RESOURCE_GROUP --sku Premium_LRS --new -z SIZE_IN_GB --name ghe-data.vhd --caching ReadWrite
|
||||
az vm disk attach --vm-name VM_NAME -g RESOURCE_GROUP --sku Premium_LRS --new -z SIZE_IN_GB --name ghe-data.vhd --caching ReadWrite
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -37,7 +37,7 @@ Before launching {% data variables.location.product_location %} on Google Cloud
|
||||
|
||||
1. Using the [gcloud compute](https://cloud.google.com/compute/docs/gcloud-compute/) command-line tool, list the public {% data variables.product.prodname_ghe_server %} images:
|
||||
```shell
|
||||
$ gcloud compute images list --project github-enterprise-public --no-standard-images
|
||||
gcloud compute images list --project github-enterprise-public --no-standard-images
|
||||
```
|
||||
|
||||
2. Take note of the image name for the latest GCE image of {% data variables.product.prodname_ghe_server %}.
|
||||
@@ -48,7 +48,7 @@ GCE virtual machines are created as a member of a network, which has a firewall.
|
||||
|
||||
1. Using the gcloud compute command-line tool, create the network. For more information, see "[gcloud compute networks create](https://cloud.google.com/sdk/gcloud/reference/compute/networks/create)" in the Google documentation.
|
||||
```shell
|
||||
$ gcloud compute networks create NETWORK-NAME --subnet-mode auto
|
||||
gcloud compute networks create NETWORK-NAME --subnet-mode auto
|
||||
```
|
||||
2. Create a firewall rule for each of the ports in the table below. For more information, see "[gcloud compute firewall-rules](https://cloud.google.com/sdk/gcloud/reference/compute/firewall-rules/)" in the Google documentation.
|
||||
```shell
|
||||
@@ -72,7 +72,7 @@ To create the {% data variables.product.prodname_ghe_server %} instance, you'll
|
||||
|
||||
1. Using the gcloud compute command-line tool, create a data disk to use as an attached storage volume for your instance data, and configure the size based on your user license count. For more information, see "[gcloud compute disks create](https://cloud.google.com/sdk/gcloud/reference/compute/disks/create)" in the Google documentation.
|
||||
```shell
|
||||
$ gcloud compute disks create DATA-DISK-NAME --size DATA-DISK-SIZE --type DATA-DISK-TYPE --zone ZONE
|
||||
gcloud compute disks create DATA-DISK-NAME --size DATA-DISK-SIZE --type DATA-DISK-TYPE --zone ZONE
|
||||
```
|
||||
|
||||
2. Then create an instance using the name of the {% data variables.product.prodname_ghe_server %} image you selected, and attach the data disk. For more information, see "[gcloud compute instances create](https://cloud.google.com/sdk/gcloud/reference/compute/instances/create)" in the Google documentation.
|
||||
|
||||
@@ -34,14 +34,14 @@ For more information about your options, see the official [MinIO docs](https://d
|
||||
|
||||
These examples use `MINIO_DIR`:
|
||||
```shell
|
||||
$ export MINIO_DIR=$(pwd)/minio
|
||||
$ mkdir -p $MINIO_DIR
|
||||
export MINIO_DIR=$(pwd)/minio
|
||||
mkdir -p $MINIO_DIR
|
||||
```
|
||||
|
||||
2. Install MinIO.
|
||||
|
||||
```shell
|
||||
$ docker pull minio/minio
|
||||
docker pull minio/minio
|
||||
```
|
||||
For more information, see the official "[MinIO Quickstart Guide](https://docs.min.io/docs/minio-quickstart-guide)."
|
||||
|
||||
@@ -66,8 +66,8 @@ For more information about your options, see the official [MinIO docs](https://d
|
||||
You can access your MinIO keys using the environment variables:
|
||||
|
||||
```shell
|
||||
$ echo $MINIO_ACCESS_KEY
|
||||
$ echo $MINIO_SECRET_KEY
|
||||
echo $MINIO_ACCESS_KEY
|
||||
echo $MINIO_SECRET_KEY
|
||||
```
|
||||
|
||||
4. Run MinIO in your chosen mode.
|
||||
@@ -91,7 +91,7 @@ For more information about your options, see the official [MinIO docs](https://d
|
||||
1. Install the MinIO client.
|
||||
|
||||
```shell
|
||||
$ docker pull minio/mc
|
||||
docker pull minio/mc
|
||||
```
|
||||
|
||||
2. Create a bucket with a host URL that {% data variables.product.prodname_ghe_server %} can access.
|
||||
@@ -99,8 +99,8 @@ For more information about your options, see the official [MinIO docs](https://d
|
||||
- Local deployments example:
|
||||
|
||||
```shell
|
||||
$ export MC_HOST_minio="http://${MINIO_ACCESS_KEY}:${MINIO_SECRET_KEY} @localhost:9000"
|
||||
$ docker run minio/mc BUCKET-NAME
|
||||
export MC_HOST_minio="http://${MINIO_ACCESS_KEY}:${MINIO_SECRET_KEY} @localhost:9000"
|
||||
docker run minio/mc BUCKET-NAME
|
||||
```
|
||||
|
||||
This example can be used for MinIO standalone.
|
||||
@@ -108,8 +108,8 @@ For more information about your options, see the official [MinIO docs](https://d
|
||||
- Clustered deployments example:
|
||||
|
||||
```shell
|
||||
$ export MC_HOST_minio="http://${MINIO_ACCESS_KEY}:${MINIO_SECRET_KEY} @minioclustername.example.com:9000"
|
||||
$ docker run minio/mc mb packages
|
||||
export MC_HOST_minio="http://${MINIO_ACCESS_KEY}:${MINIO_SECRET_KEY} @minioclustername.example.com:9000"
|
||||
docker run minio/mc mb packages
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
@@ -297,8 +297,8 @@ The unauthenticated git protocol on port 9418 is no longer supported.
|
||||
If you wish to support the unathenticated Git protocol in your environment, you must manually re-enable the feature. Run the following commands after your upgrade:
|
||||
|
||||
```ShellSession
|
||||
$ sudo ghe-config app.gitauth.git-protocol true
|
||||
$ sudo ghe-config-apply
|
||||
sudo ghe-config app.gitauth.git-protocol true
|
||||
sudo ghe-config-apply
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -46,12 +46,12 @@ You can use a Linux container management tool to build a pre-receive hook enviro
|
||||
4. Create a container:
|
||||
|
||||
```shell
|
||||
$ docker create --name pre-receive.alpine-3.3 pre-receive.alpine-3.3 /bin/true
|
||||
docker create --name pre-receive.alpine-3.3 pre-receive.alpine-3.3 /bin/true
|
||||
```
|
||||
5. Export the Docker container to a `gzip` compressed `tar` file:
|
||||
|
||||
```shell
|
||||
$ docker export pre-receive.alpine-3.3 | gzip > alpine-3.3.tar.gz
|
||||
docker export pre-receive.alpine-3.3 | gzip > alpine-3.3.tar.gz
|
||||
```
|
||||
|
||||
This file `alpine-3.3.tar.gz` is ready to be uploaded to the {% data variables.product.prodname_ghe_server %} appliance.
|
||||
@@ -61,8 +61,8 @@ You can use a Linux container management tool to build a pre-receive hook enviro
|
||||
1. Create a Linux `chroot` environment.
|
||||
2. Create a `gzip` compressed `tar` file of the `chroot` directory.
|
||||
```shell
|
||||
$ cd /path/to/chroot
|
||||
$ tar -czf /path/to/pre-receive-environment.tar.gz .
|
||||
cd /path/to/chroot
|
||||
tar -czf /path/to/pre-receive-environment.tar.gz .
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -130,7 +130,7 @@ We recommend consolidating hooks to a single repository. If the consolidated hoo
|
||||
1. For Mac users, ensure the scripts have execute permissions:
|
||||
|
||||
```shell
|
||||
$ sudo chmod +x SCRIPT_FILE.sh
|
||||
sudo chmod +x SCRIPT_FILE.sh
|
||||
```
|
||||
For Windows users, ensure the scripts have execute permissions:
|
||||
|
||||
@@ -141,8 +141,8 @@ We recommend consolidating hooks to a single repository. If the consolidated hoo
|
||||
2. Commit and push to the designated repository for pre-receive hooks on {% data variables.location.product_location %}.
|
||||
|
||||
```shell
|
||||
$ git commit -m "YOUR COMMIT MESSAGE"
|
||||
$ git push
|
||||
git commit -m "YOUR COMMIT MESSAGE"
|
||||
git push
|
||||
```
|
||||
|
||||
3. [Create the pre-receive hook](/admin/policies/enforcing-policy-with-pre-receive-hooks/managing-pre-receive-hooks-on-the-github-enterprise-server-appliance#creating-pre-receive-hooks) on the {% data variables.product.prodname_ghe_server %} instance.
|
||||
@@ -186,7 +186,7 @@ You can test a pre-receive hook script locally before you create or update it on
|
||||
4. Ensure the `always_reject.sh` scripts has execute permissions:
|
||||
|
||||
```shell
|
||||
$ chmod +x always_reject.sh
|
||||
chmod +x always_reject.sh
|
||||
```
|
||||
|
||||
5. From the directory containing `Dockerfile.dev`, build an image:
|
||||
@@ -215,13 +215,13 @@ You can test a pre-receive hook script locally before you create or update it on
|
||||
6. Run a data container that contains a generated SSH key:
|
||||
|
||||
```shell
|
||||
$ docker run --name data pre-receive.dev /bin/true
|
||||
docker run --name data pre-receive.dev /bin/true
|
||||
```
|
||||
|
||||
7. Copy the test pre-receive hook `always_reject.sh` into the data container:
|
||||
|
||||
```shell
|
||||
$ docker cp always_reject.sh data:/home/git/test.git/hooks/pre-receive
|
||||
docker cp always_reject.sh data:/home/git/test.git/hooks/pre-receive
|
||||
```
|
||||
|
||||
8. Run an application container that runs `sshd` and executes the hook. Take note of the container id that is returned:
|
||||
@@ -234,7 +234,7 @@ You can test a pre-receive hook script locally before you create or update it on
|
||||
9. Copy the generated SSH key from the data container to the local machine:
|
||||
|
||||
```shell
|
||||
$ docker cp data:/home/git/.ssh/id_ed25519 .
|
||||
docker cp data:/home/git/.ssh/id_ed25519 .
|
||||
```
|
||||
|
||||
10. Modify the remote of a test repository and push to the `test.git` repo within the Docker container. This example uses `git@github.com:octocat/Hello-World.git` but you can use any repository you want. This example assumes your local machine (127.0.0.1) is binding port 52311, but you can use a different IP address if docker is running on a remote machine.
|
||||
|
||||
@@ -99,8 +99,8 @@ For more information, see "[AUTOTITLE](/repositories/working-with-files/managing
|
||||
|
||||
3. To keep the same {% data variables.large_files.product_name_short %} configuration for each user, commit a custom `.lfsconfig` file to the repository.
|
||||
```shell
|
||||
$ git add .lfsconfig
|
||||
$ git commit -m "Adding LFS config file"
|
||||
git add .lfsconfig
|
||||
git commit -m "Adding LFS config file"
|
||||
```
|
||||
3. Migrate any existing {% data variables.large_files.product_name_short %} assets. For more information, see "[Migrating to a different {% data variables.large_files.product_name_long %} server](#migrating-to-a-different-git-large-file-storage-server)."
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ For information about promoting a user to an organization owner, see the `ghe-or
|
||||
1. [SSH](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh) into your appliance.
|
||||
2. Run [ghe-user-promote](/admin/configuration/configuring-your-enterprise/command-line-utilities#ghe-user-promote) with the username to promote.
|
||||
```shell
|
||||
$ ghe-user-promote USERNAME
|
||||
ghe-user-promote USERNAME
|
||||
```
|
||||
|
||||
## Demoting a site administrator from the command line
|
||||
@@ -59,5 +59,5 @@ For information about promoting a user to an organization owner, see the `ghe-or
|
||||
1. [SSH](/admin/configuration/configuring-your-enterprise/accessing-the-administrative-shell-ssh) into your appliance.
|
||||
2. Run [ghe-user-demote](/admin/configuration/configuring-your-enterprise/command-line-utilities#ghe-user-demote) with the username to demote.
|
||||
```shell
|
||||
$ ghe-user-demote USERNAME
|
||||
ghe-user-demote USERNAME
|
||||
```
|
||||
|
||||
@@ -65,7 +65,7 @@ As when suspending a user, unsuspending a user takes effect immediately. The use
|
||||
{% data reusables.enterprise_installation.ssh-into-instance %}
|
||||
2. Run [ghe-user-suspend](/admin/configuration/configuring-your-enterprise/command-line-utilities#ghe-user-suspend) with the username to suspend.
|
||||
```shell
|
||||
$ ghe-user-suspend USERNAME
|
||||
ghe-user-suspend USERNAME
|
||||
```
|
||||
|
||||
## Creating a custom message for suspended users
|
||||
@@ -87,7 +87,7 @@ You can create a custom message that suspended users will see when attempting to
|
||||
{% data reusables.enterprise_installation.ssh-into-instance %}
|
||||
2. Run [ghe-user-unsuspend](/admin/configuration/configuring-your-enterprise/command-line-utilities#ghe-user-unsuspend) with the username to unsuspend.
|
||||
```shell
|
||||
$ ghe-user-unsuspend USERNAME
|
||||
ghe-user-unsuspend USERNAME
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -47,7 +47,7 @@ To verify a private key:
|
||||

|
||||
1. Generate the fingerprint of your private key (PEM) locally by using the following command:
|
||||
```shell
|
||||
$ openssl rsa -in PATH_TO_PEM_FILE -pubout -outform DER | openssl sha256 -binary | openssl base64
|
||||
openssl rsa -in PATH_TO_PEM_FILE -pubout -outform DER | openssl sha256 -binary | openssl base64
|
||||
```
|
||||
1. Compare the results of the locally generated fingerprint to the fingerprint you see in {% data variables.product.product_name %}.
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ You don't need to be an expert in any of these tools or concepts to complete thi
|
||||
|
||||
1. Clone the [Creating CI tests with the Checks API](https://github.com/github-developer/creating-ci-tests-with-the-checks-api) repository.
|
||||
```shell
|
||||
$ git clone https://github.com/github-developer/creating-ci-tests-with-the-checks-api.git
|
||||
git clone https://github.com/github-developer/creating-ci-tests-with-the-checks-api.git
|
||||
```
|
||||
|
||||
Inside the directory, you'll find a `template_server.rb` file with the template code you'll use in this quickstart and a `server.rb` file with the completed project code.
|
||||
@@ -165,7 +165,7 @@ In the code above, you're using the [ternary operator](https://ruby-doc.org/core
|
||||
To test this code, restart the server from your terminal:
|
||||
|
||||
```shell
|
||||
$ ruby template_server.rb
|
||||
ruby template_server.rb
|
||||
```
|
||||
|
||||
{% data reusables.apps.sinatra_restart_instructions %}
|
||||
@@ -241,7 +241,7 @@ You'll notice in the "[AUTOTITLE](/rest/checks#update-a-check-run)" docs that wh
|
||||
You could also provide more details about what your check is doing, but you'll get to that in the next section. Let's test this code again by re-running `template_server.rb`:
|
||||
|
||||
```shell
|
||||
$ ruby template_server.rb
|
||||
ruby template_server.rb
|
||||
```
|
||||
|
||||
Head over to your open pull request and click the **Checks** tab. Click the "Re-run all" button in the upper right corner. You should see the check run move from `pending` to `in_progress` and end with `success`.
|
||||
@@ -385,7 +385,7 @@ Because this code stores the RuboCop results in a `@report` variable, it can saf
|
||||
You can test that this code works and see the errors reported by RuboCop in your server's debug output. Start up the `template_server.rb` server again and create a new pull request in the repository where you're testing your app:
|
||||
|
||||
```shell
|
||||
$ ruby template_server.rb
|
||||
ruby template_server.rb
|
||||
```
|
||||
|
||||
You should see the linting errors in the debug output, although they aren't printed with formatting. You can use a web tool like [JSON formatter](https://jsonformatter.org/) to format your JSON output like this formatted linting error output:
|
||||
@@ -575,7 +575,7 @@ The code above also adds a feature to your CI server called [requested actions](
|
||||
The code above doesn't have RuboCop automatically fix errors yet. You'll add that in the next section. But first, take a look at the CI test that you just created by starting up the `template_server.rb` server again and creating a new pull request:
|
||||
|
||||
```shell
|
||||
$ ruby template_server.rb
|
||||
ruby template_server.rb
|
||||
```
|
||||
|
||||
The annotations will show up in the **Checks** tab. Also notice the "Fix this" button that you created by adding a requested action.
|
||||
@@ -665,7 +665,7 @@ The files are changed locally, but you'll still need to push them to GitHub. You
|
||||
That's it! The code you have written now completes your Checks API CI server. 💪 Restart your `template_server.rb` server again and create a new pull request:
|
||||
|
||||
```shell
|
||||
$ ruby template_server.rb
|
||||
ruby template_server.rb
|
||||
```
|
||||
|
||||
{% data reusables.apps.sinatra_restart_instructions %}
|
||||
|
||||
@@ -50,7 +50,7 @@ But you can follow along at any experience level. We'll link out to information
|
||||
Before you begin, you'll need to clone the repository with the template code used in this quickstart. Open your Terminal app and find a directory where you'd like to store the code. Run this command to clone the [GitHub App template](https://github.com/github-developer/github-app-template) repository:
|
||||
|
||||
```shell
|
||||
$ git clone https://github.com/github-developer/github-app-template.git
|
||||
git clone https://github.com/github-developer/github-app-template.git
|
||||
```
|
||||
|
||||
## Step 1. Start a new Smee channel
|
||||
@@ -70,13 +70,13 @@ Next, go back to the Terminal and follow these steps to run the Smee command-lin
|
||||
1. Install the client:
|
||||
|
||||
```shell
|
||||
$ npm install --global smee-client
|
||||
npm install --global smee-client
|
||||
```
|
||||
|
||||
2. Run the client (replacing `https://smee.io/qrfeVRbFbffd6vD` with your own domain):
|
||||
|
||||
```shell
|
||||
$ smee --url https://smee.io/qrfeVRbFbffd6vD --path /event_handler --port 3000
|
||||
smee --url https://smee.io/qrfeVRbFbffd6vD --path /event_handler --port 3000
|
||||
```
|
||||
|
||||
You should see output like the following:
|
||||
@@ -306,19 +306,19 @@ Your app doesn't _do_ anything yet, but at this point, you can get it running on
|
||||
Keep Smee running in the current tab in your Terminal. Open a new tab and `cd` into the directory where you [cloned the template app code](#prerequisites). The Ruby code in this repository will start up a [Sinatra](https://sinatrarb.com/) web server. This code has a few dependencies. You can install these by running:
|
||||
|
||||
```shell
|
||||
$ gem install bundler
|
||||
gem install bundler
|
||||
```
|
||||
|
||||
Followed by:
|
||||
|
||||
```shell
|
||||
$ bundle install
|
||||
bundle install
|
||||
```
|
||||
|
||||
With the dependencies installed, you can start the server:
|
||||
|
||||
```shell
|
||||
$ bundle exec ruby template_server.rb
|
||||
bundle exec ruby template_server.rb
|
||||
```
|
||||
|
||||
You should see a response like:
|
||||
|
||||
@@ -44,19 +44,19 @@ If you are a site administrator for {% data variables.location.product_location
|
||||
{%- ifversion ghae %}
|
||||
<!-- GitHub AE is FIPS 140-2 compliant. FIPS does not yet permit keys that use the ed25519 algorithm. -->
|
||||
```shell
|
||||
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
|
||||
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
|
||||
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
|
||||
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
|
||||
|
||||
```
|
||||
{%- else %}
|
||||
```shell
|
||||
$ ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
```
|
||||
{% note %}
|
||||
|
||||
**Note:** If you are using a legacy system that doesn't support the Ed25519 algorithm, use:
|
||||
```shell
|
||||
$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
|
||||
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
|
||||
```
|
||||
|
||||
{% endnote %}
|
||||
@@ -118,7 +118,7 @@ Before adding a new SSH key to the ssh-agent to manage your keys, you should hav
|
||||
- If the file doesn't exist, create the file.
|
||||
|
||||
```shell
|
||||
$ touch ~/.ssh/config
|
||||
touch ~/.ssh/config
|
||||
```
|
||||
|
||||
- Open your `~/.ssh/config` file, then modify the file to contain the following lines. If your SSH key file has a different name or path than the example code, modify the filename or path to match your current setup.
|
||||
@@ -146,7 +146,7 @@ Before adding a new SSH key to the ssh-agent to manage your keys, you should hav
|
||||
|
||||
1. Add your SSH private key to the ssh-agent and store your passphrase in the keychain. {% data reusables.ssh.add-ssh-key-to-ssh-agent %}
|
||||
```shell
|
||||
$ ssh-add --apple-use-keychain ~/.ssh/id_{% ifversion ghae %}rsa{% else %}ed25519{% endif %}
|
||||
ssh-add --apple-use-keychain ~/.ssh/id_{% ifversion ghae %}rsa{% else %}ed25519{% endif %}
|
||||
```
|
||||
{% note %}
|
||||
|
||||
@@ -201,7 +201,7 @@ If you are using macOS or Linux, you may need to update your SSH client or insta
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Paste the text below, substituting in the email address for your account on {% data variables.product.product_name %}.
|
||||
```shell
|
||||
$ ssh-keygen -t {% ifversion ghae %}ecdsa{% else %}ed25519{% endif %}-sk -C "YOUR_EMAIL"
|
||||
ssh-keygen -t {% ifversion ghae %}ecdsa{% else %}ed25519{% endif %}-sk -C "YOUR_EMAIL"
|
||||
```
|
||||
|
||||
{%- ifversion not ghae %}
|
||||
@@ -209,7 +209,7 @@ If you are using macOS or Linux, you may need to update your SSH client or insta
|
||||
|
||||
**Note:** If the command fails and you receive the error `invalid format` or `feature not supported,` you may be using a hardware security key that does not support the Ed25519 algorithm. Enter the following command instead.
|
||||
```shell
|
||||
$ ssh-keygen -t ecdsa-sk -C "your_email@example.com"
|
||||
ssh-keygen -t ecdsa-sk -C "your_email@example.com"
|
||||
```
|
||||
|
||||
{% endnote %}
|
||||
|
||||
@@ -116,7 +116,7 @@ Host {% ifversion fpt or ghec %}github.com{% else %}my-GHE-hostname.com{% endif
|
||||
You can then use the hostname's alias to interact with the repository using SSH, which will use the unique deploy key assigned to that alias. For example:
|
||||
|
||||
```bash
|
||||
$ git clone git@{% ifversion fpt or ghec %}github.com{% else %}my-GHE-hostname.com{% endif %}-repo-1:OWNER/repo-1.git
|
||||
git clone git@{% ifversion fpt or ghec %}github.com{% else %}my-GHE-hostname.com{% endif %}-repo-1:OWNER/repo-1.git
|
||||
```
|
||||
|
||||
## {% data variables.product.prodname_github_app %} installation access tokens
|
||||
|
||||
@@ -148,7 +148,7 @@ ssh-add -L
|
||||
If the command says that no identity is available, you'll need to add your key:
|
||||
|
||||
```shell
|
||||
$ ssh-add YOUR-KEY
|
||||
ssh-add YOUR-KEY
|
||||
```
|
||||
|
||||
{% tip %}
|
||||
@@ -156,7 +156,7 @@ $ ssh-add YOUR-KEY
|
||||
On macOS, `ssh-agent` will "forget" this key, once it gets restarted during reboots. But you can import your SSH keys into Keychain using this command:
|
||||
|
||||
```shell
|
||||
$ ssh-add --apple-use-keychain YOUR-KEY
|
||||
ssh-add --apple-use-keychain YOUR-KEY
|
||||
```
|
||||
|
||||
For MacOS versions prior to Monterey (12.0), use `-K` instead of `--apple-use-keychain`. For more information, see "[AUTOTITLE](/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#adding-your-ssh-key-to-the-ssh-agent)."
|
||||
|
||||
@@ -51,19 +51,19 @@ The [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/) is a tool tha
|
||||
For example, to remove your file with sensitive data and leave your latest commit untouched, run:
|
||||
|
||||
```shell
|
||||
$ bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA
|
||||
bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA
|
||||
```
|
||||
|
||||
To replace all text listed in `passwords.txt` wherever it can be found in your repository's history, run:
|
||||
|
||||
```shell
|
||||
$ bfg --replace-text passwords.txt
|
||||
bfg --replace-text passwords.txt
|
||||
```
|
||||
|
||||
After the sensitive data is removed, you must force push your changes to {% data variables.product.product_name %}. Force pushing rewrites the repository history, which removes sensitive data from the commit history. If you force push, it may overwrite commits that other people have based their work on.
|
||||
|
||||
```shell
|
||||
$ git push --force
|
||||
git push --force
|
||||
```
|
||||
|
||||
See the [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/)'s documentation for full usage and download instructions.
|
||||
@@ -96,7 +96,7 @@ To illustrate how `git filter-repo` works, we'll show you how to remove your fil
|
||||
```
|
||||
3. Navigate into the repository's working directory.
|
||||
```shell
|
||||
$ cd YOUR-REPOSITORY
|
||||
cd YOUR-REPOSITORY
|
||||
```
|
||||
4. Run the following command, replacing `PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA` with the **path to the file you want to remove, not just its filename**. These arguments will:
|
||||
- Force Git to process, but not check out, the entire history of every branch and tag
|
||||
|
||||
@@ -26,11 +26,11 @@ If you're using a GPG key that matches your committer identity and your verified
|
||||
{% data reusables.gpg.copy-gpg-key-id %}
|
||||
4. Enter `gpg --edit-key GPG key ID`, substituting in the GPG key ID you'd like to use. In the following example, the GPG key ID is `3AA5C34371567BD2`:
|
||||
```shell
|
||||
$ gpg --edit-key 3AA5C34371567BD2
|
||||
gpg --edit-key 3AA5C34371567BD2
|
||||
```
|
||||
5. Enter `gpg> adduid` to add the user ID details.
|
||||
```shell
|
||||
$ gpg> adduid
|
||||
gpg> adduid
|
||||
```
|
||||
6. Follow the prompts to supply your real name, email address, and any comments. You can modify your entries by choosing `N`, `C`, or `E`. {% data reusables.gpg.private-email %} {% ifversion fpt or ghec %} For more information, see "[AUTOTITLE](/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address)."{% endif %}
|
||||
```shell
|
||||
@@ -43,7 +43,7 @@ If you're using a GPG key that matches your committer identity and your verified
|
||||
8. Enter your key's passphrase.
|
||||
9. Enter `gpg> save` to save the changes
|
||||
```shell
|
||||
$ gpg> save
|
||||
gpg> save
|
||||
```
|
||||
10. Enter `gpg --armor --export GPG key ID`, substituting in the GPG key ID you'd like to use. In the following example, the GPG key ID is `3AA5C34371567BD2`:
|
||||
```shell
|
||||
|
||||
@@ -49,9 +49,9 @@ If you have multiple GPG keys, you need to tell Git which one to use.
|
||||
```
|
||||
1. Optionally, to prompt you to enter a PIN or passphrase when required, install `pinentry-mac`. For example, using [Homebrew](https://brew.sh/):
|
||||
```shell
|
||||
$ brew install pinentry-mac
|
||||
$ echo "pinentry-program $(which pinentry-mac)" >> ~/.gnupg/gpg-agent.conf
|
||||
$ killall gpg-agent
|
||||
brew install pinentry-mac
|
||||
echo "pinentry-program $(which pinentry-mac)" >> ~/.gnupg/gpg-agent.conf
|
||||
killall gpg-agent
|
||||
```
|
||||
|
||||
{% endmac %}
|
||||
@@ -97,7 +97,7 @@ If you have multiple GPG keys, you need to tell Git which one to use.
|
||||
{% data reusables.gpg.set-auto-sign %}
|
||||
1. To add your GPG key to your `.bashrc` startup file, run the following command:
|
||||
```bash
|
||||
$ [ -f ~/.bashrc ] && echo -e '\nexport GPG_TTY=\$(tty)' >> ~/.bashrc
|
||||
[ -f ~/.bashrc ] && echo -e '\nexport GPG_TTY=\$(tty)' >> ~/.bashrc
|
||||
```
|
||||
{% endlinux %}
|
||||
{% ifversion ssh-commit-verification %}
|
||||
|
||||
@@ -29,7 +29,7 @@ The _username_ in the response is the account on {% ifversion ghae %}{% data var
|
||||
To force SSH to use only the key provided on the command line, use `-o` to add the `IdentitiesOnly=yes` option:
|
||||
|
||||
```shell
|
||||
$ ssh -v -o "IdentitiesOnly=yes" -i ~/.ssh/id_rsa git@{% data variables.command_line.codeblock %}
|
||||
ssh -v -o "IdentitiesOnly=yes" -i ~/.ssh/id_rsa git@{% data variables.command_line.codeblock %}
|
||||
```
|
||||
|
||||
## Fixing the issue
|
||||
|
||||
@@ -22,7 +22,7 @@ The `-K` option is in Apple's standard version of `ssh-add`, which stores the pa
|
||||
To add your SSH private key to the ssh-agent, you can specify the path to the Apple version of `ssh-add`:
|
||||
|
||||
```shell
|
||||
$ /usr/bin/ssh-add -K ~/.ssh/id_ed25519
|
||||
/usr/bin/ssh-add -K ~/.ssh/id_ed25519
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -37,7 +37,7 @@ If that worked, great! If not, you may need to [follow our troubleshooting guide
|
||||
Now, to clone the repository, you can run the following command:
|
||||
|
||||
```
|
||||
$ git clone ssh://git@ssh.{% data variables.command_line.codeblock %}:443/YOUR-USERNAME/YOUR-REPOSITORY.git
|
||||
git clone ssh://git@ssh.{% data variables.command_line.codeblock %}:443/YOUR-USERNAME/YOUR-REPOSITORY.git
|
||||
```
|
||||
|
||||
## Enabling SSH connections over HTTPS
|
||||
|
||||
@@ -60,8 +60,8 @@ You should always use the {% data variables.product.prodname_codeql %} bundle as
|
||||
You need to make the full contents of the {% data variables.product.prodname_codeql_cli %} bundle available to every CI server that you want to run CodeQL {% data variables.product.prodname_code_scanning %} analysis on. For example, you might configure each server to copy the bundle from a central, internal location and extract it. Alternatively, you could use the REST API to get the bundle directly from {% data variables.product.prodname_dotcom %}, ensuring that you benefit from the latest improvements to queries. Updates to the {% data variables.product.prodname_codeql_cli %} are released every 2-3 weeks. For example:
|
||||
|
||||
```shell
|
||||
$ wget https://{% ifversion fpt or ghec %}github.com{% else %}<em>HOSTNAME</em>{% endif %}/github/codeql-action/releases/latest/download/codeql-bundle-linux64.tar.gz
|
||||
$ tar -xvzf ./codeql-bundle-linux64.tar.gz
|
||||
wget https://{% ifversion fpt or ghec %}github.com{% else %}<em>HOSTNAME</em>{% endif %}/github/codeql-action/releases/latest/download/codeql-bundle-linux64.tar.gz
|
||||
tar -xvzf ./codeql-bundle-linux64.tar.gz
|
||||
```
|
||||
|
||||
After you extract the {% data variables.product.prodname_codeql_cli %} bundle, you can run the `codeql` executable on the server:
|
||||
|
||||
@@ -75,13 +75,13 @@ When {% data variables.product.prodname_github_codespaces %} creates a fork, or
|
||||
By default, source control commands that you access from your editor's user interface, such as the **Sync Changes** button in {% data variables.product.prodname_vscode_shortname %}, target your fork. If you're working from the command line, you can use `origin` to refer to your fork and `upstream` to refer to the upstream repository. For example, you can fetch changes from the upstream repository to ensure your codespace is up to date with the latest changes to the project.
|
||||
|
||||
```Shell
|
||||
$ git fetch upstream
|
||||
git fetch upstream
|
||||
```
|
||||
|
||||
When you have made some changes, you can push them to a feature branch of your fork.
|
||||
|
||||
```Shell
|
||||
$ git push origin my-feature-branch
|
||||
git push origin my-feature-branch
|
||||
```
|
||||
|
||||
For more information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks)."
|
||||
|
||||
@@ -88,7 +88,7 @@ For example, if the global `.gitconfig` file on your local machine contains a `g
|
||||
2. To remove the conflicting value from `~/.gitconfig` (Mac/Linux) or `C:\Users\YOUR-USER\.gitconfig` (Windows), use the `git config --global --unset` command.
|
||||
|
||||
```Shell
|
||||
$ git config --global --unset gpg.program
|
||||
git config --global --unset gpg.program
|
||||
```
|
||||
3. Push the change to your dotfiles repository on {% data variables.product.prodname_dotcom %}.
|
||||
4. Optionally, to keep your local configuration, set the value again in a Git configuration file that you do not push to your dotfiles repository.
|
||||
@@ -96,7 +96,7 @@ For example, if the global `.gitconfig` file on your local machine contains a `g
|
||||
For example, you can use the `--system` flag to set the configuration in the system-level file at `PATH/etc/gitconfig`, where `PATH` is the directory in which Git is installed on your system.
|
||||
|
||||
```Shell
|
||||
$ git config --system gpg.program gpg2
|
||||
git config --system gpg.program gpg2
|
||||
```
|
||||
|
||||
Alternatively, if your dotfiles repository contains an installation script in a recognized file such as `install.sh`, you can use the `$CODESPACES` environment variable to add conditional logic, such as only setting `gpg.program` when you are not in a codespace. In the following example, `-z "$CODESPACES"` returns `true` if you are not in a codespace.
|
||||
|
||||
@@ -16,7 +16,7 @@ versions:
|
||||
3. {% data reusables.desktop.launch-desktop-from-command-line %}
|
||||
|
||||
```shell
|
||||
$ github /PATH/TO/REPO
|
||||
github /PATH/TO/REPO
|
||||
```
|
||||
|
||||
You can also change to your repository path and then type `github .` to open that repository.
|
||||
|
||||
@@ -25,7 +25,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "code --wait"
|
||||
git config --global core.editor "code --wait"
|
||||
```
|
||||
|
||||
{% endmac %}
|
||||
@@ -36,7 +36,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "code --wait"
|
||||
git config --global core.editor "code --wait"
|
||||
```
|
||||
|
||||
{% endwindows %}
|
||||
@@ -47,7 +47,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "code --wait"
|
||||
git config --global core.editor "code --wait"
|
||||
```
|
||||
|
||||
{% endlinux %}
|
||||
@@ -60,7 +60,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "subl -n -w"
|
||||
git config --global core.editor "subl -n -w"
|
||||
```
|
||||
|
||||
{% endmac %}
|
||||
@@ -71,7 +71,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "'C:/Program Files (x86)/sublime text 3/subl.exe' -w"
|
||||
git config --global core.editor "'C:/Program Files (x86)/sublime text 3/subl.exe' -w"
|
||||
```
|
||||
|
||||
{% endwindows %}
|
||||
@@ -82,7 +82,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "subl -n -w"
|
||||
git config --global core.editor "subl -n -w"
|
||||
```
|
||||
|
||||
{% endlinux %}
|
||||
@@ -96,7 +96,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "mate -w"
|
||||
git config --global core.editor "mate -w"
|
||||
```
|
||||
|
||||
{% endmac %}
|
||||
@@ -109,7 +109,7 @@ shortTitle: Associate text editors
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. Type this command:
|
||||
```shell
|
||||
$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
|
||||
git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
|
||||
```
|
||||
|
||||
{% endwindows %}
|
||||
|
||||
@@ -41,13 +41,13 @@ For more information about authenticating with {% data variables.product.prodnam
|
||||
|
||||
1. Install Git using [Homebrew](https://brew.sh/):
|
||||
```shell
|
||||
$ brew install git
|
||||
brew install git
|
||||
```
|
||||
|
||||
2. Install GCM using Homebrew:
|
||||
```shell
|
||||
$ brew tap microsoft/git
|
||||
$ brew install --cask git-credential-manager-core
|
||||
brew tap microsoft/git
|
||||
brew install --cask git-credential-manager-core
|
||||
```
|
||||
For MacOS, you don't need to run `git config` because GCM automatically configures Git for you.
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ GitHub maintains an official list of recommended _.gitignore_ files for many pop
|
||||
2. Navigate to the location of your Git repository.
|
||||
3. Create a _.gitignore_ file for your repository.
|
||||
```shell
|
||||
$ touch .gitignore
|
||||
touch .gitignore
|
||||
```
|
||||
|
||||
If the command succeeds, there will be no output.
|
||||
@@ -35,7 +35,7 @@ For an example _.gitignore_ file, see "[Some common .gitignore configurations](h
|
||||
If you want to ignore a file that is already checked in, you must untrack the file before you add a rule to ignore it. From your terminal, untrack the file.
|
||||
|
||||
```shell
|
||||
$ git rm --cached FILENAME
|
||||
git rm --cached FILENAME
|
||||
```
|
||||
|
||||
## Configuring ignored files for all repositories on your computer
|
||||
@@ -45,7 +45,7 @@ You can also create a global _.gitignore_ file to define a list of rules for ign
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Configure Git to use the exclude file _~/.gitignore_global_ for all Git repositories.
|
||||
```shell
|
||||
$ git config --global core.excludesfile ~/.gitignore_global
|
||||
git config --global core.excludesfile ~/.gitignore_global
|
||||
```
|
||||
|
||||
## Excluding local files without creating a _.gitignore_ file
|
||||
|
||||
@@ -96,7 +96,7 @@ The `git remote set-url` command takes two arguments:
|
||||
```
|
||||
4. Change your remote's URL from SSH to HTTPS with the `git remote set-url` command.
|
||||
```shell
|
||||
$ git remote set-url origin https://{% data variables.command_line.codeblock %}/OWNER/REPOSITORY.git
|
||||
git remote set-url origin https://{% data variables.command_line.codeblock %}/OWNER/REPOSITORY.git
|
||||
```
|
||||
5. Verify that the remote URL has changed.
|
||||
```shell
|
||||
@@ -122,7 +122,7 @@ You can [use a credential helper](/get-started/getting-started-with-git/caching-
|
||||
```
|
||||
4. Change your remote's URL from HTTPS to SSH with the `git remote set-url` command.
|
||||
```shell
|
||||
$ git remote set-url origin git@{% data variables.command_line.codeblock %}:OWNER/REPOSITORY.git
|
||||
git remote set-url origin git@{% data variables.command_line.codeblock %}:OWNER/REPOSITORY.git
|
||||
```
|
||||
5. Verify that the remote URL has changed.
|
||||
```shell
|
||||
|
||||
@@ -24,7 +24,7 @@ Changing the name associated with your Git commits using `git config` will only
|
||||
|
||||
2. {% data reusables.user-settings.set_your_git_username %}
|
||||
```shell
|
||||
$ git config --global user.name "Mona Lisa"
|
||||
git config --global user.name "Mona Lisa"
|
||||
```
|
||||
|
||||
3. {% data reusables.user-settings.confirm_git_username_correct %}
|
||||
@@ -41,7 +41,7 @@ Changing the name associated with your Git commits using `git config` will only
|
||||
|
||||
3. {% data reusables.user-settings.set_your_git_username %}
|
||||
```shell
|
||||
$ git config user.name "Mona Lisa"
|
||||
git config user.name "Mona Lisa"
|
||||
```
|
||||
|
||||
3. {% data reusables.user-settings.confirm_git_username_correct %}
|
||||
|
||||
@@ -60,7 +60,7 @@ You can clone your fork with the command line, {% data variables.product.prodnam
|
||||
{% data reusables.command_line.change-current-directory-clone %}
|
||||
4. Type `git clone`, and then paste the URL you copied earlier. It will look like this, with your {% data variables.product.product_name %} username instead of `YOUR-USERNAME`:
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/YOUR-USERNAME/Spoon-Knife
|
||||
git clone https://{% data variables.command_line.codeblock %}/YOUR-USERNAME/Spoon-Knife
|
||||
```
|
||||
|
||||
5. Press **Enter**. Your local clone will be created.
|
||||
|
||||
@@ -114,7 +114,7 @@ Right now, you have a fork of the Spoon-Knife repository, but you do not have th
|
||||
{% data reusables.command_line.change-current-directory-clone %}
|
||||
4. Type `git clone`, and then paste the URL you copied earlier. It will look like this, with your {% data variables.product.product_name %} username instead of `YOUR-USERNAME`:
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/YOUR-USERNAME/Spoon-Knife
|
||||
git clone https://{% data variables.command_line.codeblock %}/YOUR-USERNAME/Spoon-Knife
|
||||
```
|
||||
|
||||
5. Press **Enter**. Your local clone will be created.
|
||||
@@ -174,7 +174,7 @@ When you fork a project in order to propose changes to the upstream repository,
|
||||
|
||||
6. Type `git remote add upstream`, and then paste the URL you copied in Step 3 and press **Enter**. It will look like this:
|
||||
```shell
|
||||
$ git remote add upstream https://{% data variables.command_line.codeblock %}/ORIGINAL_OWNER/Spoon-Knife.git
|
||||
git remote add upstream https://{% data variables.command_line.codeblock %}/ORIGINAL_OWNER/Spoon-Knife.git
|
||||
```
|
||||
|
||||
7. To verify the new upstream repository you have specified for your fork, type `git remote -v` again. You should see the URL for your fork as `origin`, and the URL for the upstream repository as `upstream`.
|
||||
|
||||
@@ -31,7 +31,7 @@ Typically, you would use `git rebase` to:
|
||||
To rebase all the commits between another branch and the current branch state, you can enter the following command in your shell (either the command prompt for Windows, or the terminal for Mac and Linux):
|
||||
|
||||
```shell
|
||||
$ git rebase --interactive OTHER-BRANCH-NAME
|
||||
git rebase --interactive OTHER-BRANCH-NAME
|
||||
```
|
||||
|
||||
## Rebasing commits against a point in time
|
||||
@@ -39,7 +39,7 @@ $ git rebase --interactive OTHER-BRANCH-NAME
|
||||
To rebase the last few commits in your current branch, you can enter the following command in your shell:
|
||||
|
||||
```shell
|
||||
$ git rebase --interactive HEAD~7
|
||||
git rebase --interactive HEAD~7
|
||||
```
|
||||
|
||||
## Commands available while rebasing
|
||||
|
||||
@@ -30,8 +30,8 @@ The best way to explain subtree merges is to show by example. We will:
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Create a new directory and navigate to it.
|
||||
```shell
|
||||
$ mkdir test
|
||||
$ cd test
|
||||
mkdir test
|
||||
cd test
|
||||
```
|
||||
3. Initialize a new Git repository.
|
||||
```shell
|
||||
@@ -100,13 +100,13 @@ Although we've only added one subproject, any number of subprojects can be incor
|
||||
When a subproject is added, it is not automatically kept in sync with the upstream changes. You will need to update the subproject with the following command:
|
||||
|
||||
```shell
|
||||
$ git pull -s subtree REMOTE-NAME BRANCH-NAME
|
||||
git pull -s subtree REMOTE-NAME BRANCH-NAME
|
||||
```
|
||||
|
||||
For the example above, this would be:
|
||||
|
||||
```shell
|
||||
$ git pull -s subtree spoon-knife main
|
||||
git pull -s subtree spoon-knife main
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -22,12 +22,12 @@ If you create a new clone of the repository, you won't lose any of your Git hist
|
||||
|
||||
4. Clone the repository that contains the subfolder.
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/USERNAME/REPOSITORY-NAME
|
||||
git clone https://{% data variables.command_line.codeblock %}/USERNAME/REPOSITORY-NAME
|
||||
```
|
||||
|
||||
4. Change the current working directory to your cloned repository.
|
||||
```shell
|
||||
$ cd REPOSITORY-NAME
|
||||
cd REPOSITORY-NAME
|
||||
```
|
||||
|
||||
5. To filter out the subfolder from the rest of the files in the repository, install [`git-filter-repo`](https://github.com/newren/git-filter-repo), then run `git filter-repo` with the following arguments.
|
||||
|
||||
@@ -110,13 +110,13 @@ $ svn commit -m 'Test coverage for problems'
|
||||
To switch between branches, you'll probably want to start with a checkout of `trunk`:
|
||||
|
||||
```shell
|
||||
$ svn co --depth empty https://github.com/USER/REPO/trunk
|
||||
svn co --depth empty https://github.com/USER/REPO/trunk
|
||||
```
|
||||
|
||||
Then, you can switch to another branch:
|
||||
|
||||
```shell
|
||||
$ svn switch https://github.com/USER/REPO/branches/more_awesome
|
||||
svn switch https://github.com/USER/REPO/branches/more_awesome
|
||||
```
|
||||
|
||||
## Finding the Git commit SHA for a Subversion commit
|
||||
|
||||
@@ -116,7 +116,7 @@ GraphQL is [introspective](https://graphql.github.io/learn/introspection/). This
|
||||
- You can also run an _introspection query_ of the schema via a `GET` request:
|
||||
|
||||
```shell
|
||||
$ curl -H "Authorization: bearer TOKEN" {% data variables.product.graphql_url_pre %}
|
||||
curl -H "Authorization: bearer TOKEN" {% data variables.product.graphql_url_pre %}
|
||||
```
|
||||
|
||||
{% note %}
|
||||
|
||||
@@ -35,7 +35,7 @@ Let's walk through an example.
|
||||
If you [request the authenticated user](/rest/users#get-the-authenticated-user):
|
||||
|
||||
```shell
|
||||
$ curl -i --header "Authorization: Bearer YOUR-TOKEN" {% data variables.product.api_url_pre %}/user
|
||||
curl -i --header "Authorization: Bearer YOUR-TOKEN" {% data variables.product.api_url_pre %}/user
|
||||
```
|
||||
|
||||
you'll get a response that includes the `node_id` of the authenticated user:
|
||||
|
||||
@@ -44,8 +44,8 @@ For purposes of demonstration, we'll use:
|
||||
```
|
||||
4. Remove the temporary local repository.
|
||||
```shell
|
||||
$ cd ..
|
||||
$ rm -rf REPO.git
|
||||
cd ..
|
||||
rm -rf REPO.git
|
||||
```
|
||||
|
||||
If the repository you are importing contains large files, you may run into a warning or error. For more information on large files and how to manage them, see "[AUTOTITLE](/repositories/working-with-files/managing-large-files/about-large-files-on-github)."
|
||||
|
||||
@@ -27,13 +27,13 @@ permissions: Site administrators can use the administrative shell to import data
|
||||
{% data reusables.enterprise_migrations.review-the-import-csv %}
|
||||
4. Rewrite the authors and branches using the CSV file:
|
||||
```shell
|
||||
$ git-import-rewrite --flavor hg --authors /PATH/AUTHORS-MAP-FILE.csv /PATH/REPO-NAME.git
|
||||
git-import-rewrite --flavor hg --authors /PATH/AUTHORS-MAP-FILE.csv /PATH/REPO-NAME.git
|
||||
```
|
||||
5. If you haven't yet, [create a new empty repository on {% data variables.product.prodname_ghe_server %}](/repositories/creating-and-managing-repositories/creating-a-new-repository).
|
||||
{% data reusables.command_line.switching_directories_procedural %}
|
||||
7. Push the imported repository to {% data variables.product.prodname_ghe_server %}:
|
||||
```shell
|
||||
$ git push --mirror PUSH-URL-ON-GITHUB-ENTERPRISE
|
||||
git push --mirror PUSH-URL-ON-GITHUB-ENTERPRISE
|
||||
```
|
||||
|
||||
## Importing projects from Subversion
|
||||
@@ -47,13 +47,13 @@ permissions: Site administrators can use the administrative shell to import data
|
||||
{% data reusables.enterprise_migrations.review-the-import-csv %}
|
||||
4. Rewrite the authors and branches using the CSV file:
|
||||
```shell
|
||||
$ git-import-rewrite --flavor svn --authors /PATH/AUTHORS-MAP-FILE.csv /PATH/REPO-NAME.git
|
||||
git-import-rewrite --flavor svn --authors /PATH/AUTHORS-MAP-FILE.csv /PATH/REPO-NAME.git
|
||||
```
|
||||
5. If you haven't yet, [create a new empty repository on {% data variables.product.prodname_ghe_server %}](/repositories/creating-and-managing-repositories/creating-a-new-repository).
|
||||
{% data reusables.command_line.switching_directories_procedural %}
|
||||
7. Push the imported repository to {% data variables.product.prodname_ghe_server %}:
|
||||
```shell
|
||||
$ git push --mirror PUSH-URL-ON-GITHUB-ENTERPRISE
|
||||
git push --mirror PUSH-URL-ON-GITHUB-ENTERPRISE
|
||||
```
|
||||
|
||||
## Importing projects from Team Foundation Version Control
|
||||
@@ -67,13 +67,13 @@ permissions: Site administrators can use the administrative shell to import data
|
||||
{% data reusables.enterprise_migrations.review-the-import-csv %}
|
||||
4. Rewrite the authors and branches using the CSV file:
|
||||
```shell
|
||||
$ git-import-rewrite --flavor tfs --authors /PATH/AUTHORS-MAP-FILE.csv /PATH/REPO_NAME.git
|
||||
git-import-rewrite --flavor tfs --authors /PATH/AUTHORS-MAP-FILE.csv /PATH/REPO_NAME.git
|
||||
```
|
||||
5. If you haven't yet, [create a new empty repository on {% data variables.product.prodname_ghe_server %}](/repositories/creating-and-managing-repositories/creating-a-new-repository).
|
||||
{% data reusables.command_line.switching_directories_procedural %}
|
||||
7. Push the imported repository to {% data variables.product.prodname_ghe_server %}:
|
||||
```shell
|
||||
$ git push --mirror PUSH-URL-ON-GITHUB-ENTERPRISE
|
||||
git push --mirror PUSH-URL-ON-GITHUB-ENTERPRISE
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -81,7 +81,7 @@ shortTitle: Export from GHES
|
||||
|
||||
6. To add more repositories to the same export, use the `ghe-migrator add` command with the `-g` flag. You'll pass in the new repository URL and the Migration GUID from Step 5:
|
||||
```shell
|
||||
$ ghe-migrator add https://HOSTNAME/USERNAME/OTHER-REPO-NAME -g MIGRATION-GUID --lock
|
||||
ghe-migrator add https://HOSTNAME/USERNAME/OTHER-REPO-NAME -g MIGRATION-GUID --lock
|
||||
```
|
||||
7. When you've finished adding repositories, generate the migration archive using the `ghe-migrator export` command with the `-g` flag and the Migration GUID from Step 5:
|
||||
```shell
|
||||
@@ -98,6 +98,6 @@ shortTitle: Export from GHES
|
||||
```
|
||||
9. Copy the migration archive to your computer using the [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) command. The archive file will be named with the Migration GUID:
|
||||
```shell
|
||||
$ scp -P 122 admin@HOSTNAME:/data/github/current/tmp/MIGRATION-GUID.tar.gz ~/Desktop
|
||||
scp -P 122 admin@HOSTNAME:/data/github/current/tmp/MIGRATION-GUID.tar.gz ~/Desktop
|
||||
```
|
||||
{% data reusables.enterprise_migrations.ready-to-import-migrations %}
|
||||
|
||||
@@ -99,7 +99,7 @@ The record types match those found in the [migrated data](/migrations/using-ghe-
|
||||
With the `ghe-migrator audit` command, you can filter based on the record type using the `-m` flag. Similarly, you can filter on the import state using the `-s` flag. The command looks like this:
|
||||
|
||||
```shell
|
||||
$ ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
|
||||
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
|
||||
```
|
||||
|
||||
For example, to view every successfully imported organization and team, you would enter:
|
||||
|
||||
@@ -26,7 +26,7 @@ shortTitle: Prepare to migrate data
|
||||
1. Using the [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) command, copy the migration archive generated from your source instance or organization to your {% data variables.product.prodname_ghe_server %} target:
|
||||
|
||||
```shell
|
||||
$ scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
|
||||
scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
|
||||
```
|
||||
|
||||
{% data reusables.enterprise_installation.ssh-into-target-instance %}
|
||||
@@ -44,12 +44,12 @@ shortTitle: Prepare to migrate data
|
||||
|
||||
1. Using the `ghe-migrator conflicts` command with the Migration GUID, generate a _conflicts.csv_ file:
|
||||
```shell
|
||||
$ ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
|
||||
ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
|
||||
```
|
||||
- If no conflicts are reported, you can safely import the data by following the steps in "[AUTOTITLE](/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server)".
|
||||
2. If there are conflicts, using the [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) command, copy _conflicts.csv_ to your local computer:
|
||||
```shell
|
||||
$ scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
|
||||
scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
|
||||
```
|
||||
3. Continue to "[Resolving migration conflicts or setting up custom mappings](#resolving-migration-conflicts-or-setting-up-custom-mappings)".
|
||||
|
||||
@@ -121,7 +121,7 @@ Given a list of usernames from the source and a list of usernames on the target,
|
||||
You can quickly generate a CSV of users being migrated in the CSV format needed to apply custom mappings by using the [`ghe-migrator audit`](/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server) command:
|
||||
|
||||
```shell
|
||||
$ ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
|
||||
ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
|
||||
```
|
||||
|
||||
Now, you can edit that CSV and enter the new URL for each user you would like to map or rename, and then update the fourth column to have `map` or `rename` as appropriate.
|
||||
@@ -139,13 +139,13 @@ The same process can be used to create mappings for each record that supports cu
|
||||
1. After making changes, use the [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) command to apply your modified _conflicts.csv_ (or any other mapping _.csv_ file in the correct format) to the target instance:
|
||||
|
||||
```shell
|
||||
$ scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
|
||||
scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
|
||||
```
|
||||
|
||||
2. Re-map the migration data using the `ghe-migrator map` command, passing in the path to your modified _.csv_ file and the Migration GUID:
|
||||
|
||||
```shell
|
||||
$ ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
|
||||
ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
|
||||
```
|
||||
|
||||
3. If the `ghe-migrator map -i conflicts.csv -g MIGRATION-GUID` command reports that conflicts still exist, run through the migration conflict resolution process again.
|
||||
|
||||
@@ -51,7 +51,7 @@ When you issue each certificate, you must include an extension that specifies wh
|
||||
{% endnote %}
|
||||
|
||||
```shell
|
||||
$ ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@{% data variables.product.product_url %}=USERNAME ./user-key.pub
|
||||
ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@{% data variables.product.product_url %}=USERNAME ./user-key.pub
|
||||
```
|
||||
|
||||
{% warning %}
|
||||
@@ -63,11 +63,11 @@ $ ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@{% data var
|
||||
To issue a certificate for someone who uses SSH to access multiple {% data variables.product.company_short %} products, you can include two login extensions to specify the username for each product. For example, the following command would issue a certificate for USERNAME-1 for the user's account for {% data variables.product.prodname_ghe_cloud %}, and USERNAME-2 for the user's account on {% data variables.product.prodname_ghe_managed %} or {% data variables.product.prodname_ghe_server %} at HOSTNAME.
|
||||
|
||||
```shell
|
||||
$ ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME-1 extension:login@HOSTNAME=USERNAME-2 ./user-key.pub
|
||||
ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME-1 extension:login@HOSTNAME=USERNAME-2 ./user-key.pub
|
||||
```
|
||||
|
||||
You can restrict the IP addresses from which an organization member can access your organization's resources by using a `source-address` extension. The extension accepts a specific IP address or a range of IP addresses using CIDR notation. You can specify multiple addresses or ranges by separating the values with commas. For more information, see "[Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation)" on Wikipedia.
|
||||
|
||||
```shell
|
||||
$ ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@{% data variables.product.product_url %}=USERNAME -O source-address=COMMA-SEPARATED-LIST-OF-IP-ADDRESSES-OR-RANGES ./user-key.pub
|
||||
ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@{% data variables.product.product_url %}=USERNAME -O source-address=COMMA-SEPARATED-LIST-OF-IP-ADDRESSES-OR-RANGES ./user-key.pub
|
||||
```
|
||||
|
||||
@@ -70,7 +70,7 @@ To verify a domain, you must have access to modify domain records with your doma
|
||||
{% data reusables.organizations.add-dns-txt-record %}
|
||||
1. Wait for your DNS configuration to change, which may take up to 72 hours. You can confirm your DNS configuration has changed by running the `dig` command on the command line, replacing `ORGANIZATION` with the name of your organization and `example.com` with the domain you'd like to verify. You should see your new TXT record listed in the command output.
|
||||
```shell
|
||||
$ dig _github-challenge-ORGANIZATION-org.example.com +nostats +nocomments +nocmd TXT
|
||||
dig _github-challenge-ORGANIZATION-org.example.com +nostats +nocomments +nocmd TXT
|
||||
```
|
||||
1. After confirming your TXT record is added to your DNS, follow steps one through three above to navigate to your organization's approved and verified domains.
|
||||
{% data reusables.organizations.continue-verifying-domain %}
|
||||
|
||||
@@ -49,7 +49,7 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
2. Build your container image. This example builds an image from the Dockerfile in the current directory and assigns the image name `hello_docker`.
|
||||
|
||||
```shell
|
||||
$ docker build -t hello_docker .
|
||||
docker build -t hello_docker .
|
||||
```
|
||||
|
||||
3. Optionally, review the details of the Docker image you just created.
|
||||
@@ -63,14 +63,14 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
|
||||
4. Assign a name and hosting destination to your Docker image.
|
||||
```shell
|
||||
$ docker tag IMAGE_NAME {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/NEW_IMAGE_NAME:TAG
|
||||
docker tag IMAGE_NAME {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/NEW_IMAGE_NAME:TAG
|
||||
```
|
||||
|
||||
Replace `NAMESPACE` with the name of the personal account or organization to which you want the package to be scoped.
|
||||
|
||||
For example:
|
||||
```shell
|
||||
$ docker tag 38f737a91f39 {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
docker tag 38f737a91f39 {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
```
|
||||
|
||||
5. If you haven't already, authenticate to the {% data variables.product.prodname_container_registry %}. For more information, see "[AUTOTITLE](/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry)."
|
||||
@@ -82,10 +82,10 @@ When you publish a package that is scoped to a personal account or an organizati
|
||||
{% endraw %}
|
||||
6. Push your container image to the {% data variables.product.prodname_container_registry %}.
|
||||
```shell
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE-NAME:TAG
|
||||
docker push {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE-NAME:TAG
|
||||
```
|
||||
For example:
|
||||
```shell
|
||||
$ docker push {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
docker push {% ifversion fpt or ghec %}ghcr.io{% elsif ghes > 3.4 %}{% data reusables.package_registry.container-registry-example-hostname %}{% endif %}/octocat/hello_docker:latest
|
||||
```
|
||||
{% endif %}
|
||||
|
||||
@@ -21,8 +21,8 @@ In this guide, you'll create a {% data variables.product.prodname_actions %} wor
|
||||
1. Create a new repository on {% data variables.product.prodname_dotcom %}, adding the `.gitignore` for Node. For more information, see "[AUTOTITLE](/repositories/creating-and-managing-repositories/creating-a-new-repository)."
|
||||
2. Clone the repository to your local machine.
|
||||
```shell
|
||||
$ git clone https://{% ifversion ghes or ghae %}YOUR-HOSTNAME{% else %}github.com{% endif %}/YOUR-USERNAME/YOUR-REPOSITORY.git
|
||||
$ cd YOUR-REPOSITORY
|
||||
git clone https://{% ifversion ghes or ghae %}YOUR-HOSTNAME{% else %}github.com{% endif %}/YOUR-USERNAME/YOUR-REPOSITORY.git
|
||||
cd YOUR-REPOSITORY
|
||||
```
|
||||
3. Create an `index.js` file and add a basic alert to say "Hello world!"
|
||||
{% raw %}
|
||||
@@ -43,10 +43,10 @@ In this guide, you'll create a {% data variables.product.prodname_actions %} wor
|
||||
{% endraw %}
|
||||
5. Run `npm install` to generate the `package-lock.json` file, then commit and push your changes to {% data variables.product.prodname_dotcom %}.
|
||||
```shell
|
||||
$ npm install
|
||||
$ git add index.js package.json package-lock.json
|
||||
$ git commit -m "initialize npm package"
|
||||
$ git push
|
||||
npm install
|
||||
git add index.js package.json package-lock.json
|
||||
git commit -m "initialize npm package"
|
||||
git push
|
||||
```
|
||||
6. Create a `.github/workflows` directory. In that directory, create a file named `release-package.yml`.
|
||||
7. Copy the following YAML content into the `release-package.yml` file{% ifversion ghes or ghae %}, replacing `YOUR-HOSTNAME` with the name of your enterprise{% endif %}.
|
||||
|
||||
@@ -160,7 +160,7 @@ For more information on creating a package, see the [maven.apache.org documentat
|
||||
{% data reusables.package_registry.checksum-maven-plugin %}
|
||||
1. Publish the package.
|
||||
```shell
|
||||
$ mvn deploy
|
||||
mvn deploy
|
||||
```
|
||||
|
||||
{% data reusables.package_registry.viewing-packages %}
|
||||
@@ -185,7 +185,7 @@ To install an Apache Maven package from {% data variables.product.prodname_regis
|
||||
3. Install the package.
|
||||
|
||||
```shell
|
||||
$ mvn install
|
||||
mvn install
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -64,7 +64,7 @@ This registry supports granular permissions. {% data reusables.package_registry.
|
||||
This example pushes the latest version of `IMAGE_NAME`.
|
||||
|
||||
```shell
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:latest
|
||||
docker push {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:latest
|
||||
```
|
||||
|
||||
Replace `NAMESPACE` with the name of the personal account or organization to which you want the image to be scoped.
|
||||
@@ -72,7 +72,7 @@ Replace `NAMESPACE` with the name of the personal account or organization to whi
|
||||
This example pushes the `2.5` version of the image.
|
||||
|
||||
```shell
|
||||
$ docker push {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:2.5
|
||||
docker push {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:2.5
|
||||
```
|
||||
|
||||
{% data reusables.package_registry.publishing-user-scoped-packages %} You can link a published package to a repository using the user interface or command line. For more information, see "[AUTOTITLE](/packages/learn-github-packages/connecting-a-repository-to-a-package)."
|
||||
@@ -91,24 +91,24 @@ To ensure you're always using the same image, you can specify the exact containe
|
||||
|
||||
1. To find the digest SHA value, use `docker inspect` or `docker pull` and copy the SHA value after `Digest:`
|
||||
```shell
|
||||
$ docker inspect {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME
|
||||
docker inspect {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME
|
||||
```
|
||||
|
||||
Replace `NAMESPACE` with the name of the personal account or organization to which the image is scoped.
|
||||
2. Remove image locally as needed.
|
||||
```shell
|
||||
$ docker rmi {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:latest
|
||||
docker rmi {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME:latest
|
||||
```
|
||||
|
||||
3. Pull the container image with `@YOUR_SHA_VALUE` after the image name.
|
||||
```shell
|
||||
$ docker pull {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs
|
||||
docker pull {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME@sha256:82jf9a84u29hiasldj289498uhois8498hjs29hkuhs
|
||||
```
|
||||
|
||||
### Pull by name
|
||||
|
||||
```shell
|
||||
$ docker pull {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME
|
||||
docker pull {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/IMAGE_NAME
|
||||
```
|
||||
|
||||
Replace `NAMESPACE` with the name of the personal account or organization to which the image is scoped.
|
||||
@@ -147,7 +147,7 @@ Replace `NAMESPACE` with the name of the personal account or organization to whi
|
||||
This example builds the `hello_docker` image:
|
||||
|
||||
```shell
|
||||
$ docker build -t hello_docker .
|
||||
docker build -t hello_docker .
|
||||
```
|
||||
|
||||
## Tagging container images
|
||||
@@ -162,7 +162,7 @@ $ docker build -t hello_docker .
|
||||
|
||||
2. Tag your Docker image using the image ID and your desired image name and hosting destination.
|
||||
```shell
|
||||
$ docker tag 38f737a91f39 {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/NEW_IMAGE_NAME:latest
|
||||
docker tag 38f737a91f39 {% data reusables.package_registry.container-registry-hostname %}/NAMESPACE/NEW_IMAGE_NAME:latest
|
||||
```
|
||||
|
||||
Replace `NAMESPACE` with the name of the personal account or organization to which you want the image to be scoped.
|
||||
|
||||
@@ -53,7 +53,7 @@ To keep your credentials secure, we recommend you save your {% data variables.pr
|
||||
{% ifversion fpt or ghec %}
|
||||
{% raw %}
|
||||
```shell
|
||||
$ cat ~/TOKEN.txt | docker login https://docker.pkg.github.com -u <em>USERNAME</em> --password-stdin
|
||||
cat ~/TOKEN.txt | docker login https://docker.pkg.github.com -u <em>USERNAME</em> --password-stdin
|
||||
```
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
@@ -64,7 +64,7 @@ If your instance has subdomain isolation enabled:
|
||||
{% endif %}
|
||||
{% raw %}
|
||||
```shell
|
||||
$ cat ~/TOKEN.txt | docker login docker.HOSTNAME -u USERNAME --password-stdin
|
||||
cat ~/TOKEN.txt | docker login docker.HOSTNAME -u USERNAME --password-stdin
|
||||
```
|
||||
{% endraw %}
|
||||
{% ifversion ghes %}
|
||||
@@ -72,7 +72,7 @@ If your instance has subdomain isolation disabled:
|
||||
|
||||
{% raw %}
|
||||
```shell
|
||||
$ cat ~/TOKEN.txt | docker login HOSTNAME -u USERNAME --password-stdin
|
||||
cat ~/TOKEN.txt | docker login HOSTNAME -u USERNAME --password-stdin
|
||||
```
|
||||
{% endraw %}
|
||||
{% endif %}
|
||||
@@ -107,57 +107,57 @@ For more information, see "[Docker login](https://docs.docker.com/engine/referen
|
||||
2. Using the Docker image ID, tag the docker image, replacing OWNER with the name of the personal account or organization that owns the repository, REPOSITORY with the name of the repository containing your project, IMAGE_NAME with name of the package or image,{% ifversion ghes or ghae %} HOSTNAME with the hostname of {% data variables.location.product_location %},{% endif %} and VERSION with package version at build time.
|
||||
{% ifversion fpt or ghec %}
|
||||
```shell
|
||||
$ docker tag IMAGE_ID docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
docker tag IMAGE_ID docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
```
|
||||
{% else %}
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation enabled:
|
||||
{% endif %}
|
||||
```shell
|
||||
$ docker tag IMAGE_ID docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
docker tag IMAGE_ID docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
```
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation disabled:
|
||||
```shell
|
||||
$ docker tag IMAGE_ID HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
docker tag IMAGE_ID HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
```
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
3. If you haven't already built a docker image for the package, build the image, replacing OWNER with the name of the personal account or organization that owns the repository, REPOSITORY with the name of the repository containing your project, IMAGE_NAME with name of the package or image, VERSION with package version at build time,{% ifversion ghes or ghae %} HOSTNAME with the hostname of {% data variables.location.product_location %},{% endif %} and PATH to the image if it isn't in the current working directory.
|
||||
{% ifversion fpt or ghec %}
|
||||
```shell
|
||||
$ docker build -t docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
|
||||
docker build -t docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
|
||||
```
|
||||
{% else %}
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation enabled:
|
||||
{% endif %}
|
||||
```shell
|
||||
$ docker build -t docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
|
||||
docker build -t docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
|
||||
```
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation disabled:
|
||||
```shell
|
||||
$ docker build -t HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
|
||||
docker build -t HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
|
||||
```
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
4. Publish the image to {% data variables.product.prodname_registry %}.
|
||||
{% ifversion fpt or ghec %}
|
||||
```shell
|
||||
$ docker push docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
docker push docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
```
|
||||
{% else %}
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation enabled:
|
||||
{% endif %}
|
||||
```shell
|
||||
$ docker push docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
docker push docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
```
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation disabled:
|
||||
```shell
|
||||
$ docker push HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
docker push HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
|
||||
```
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
@@ -237,7 +237,7 @@ You can use the `docker pull` command to install a docker image from {% data var
|
||||
|
||||
{% ifversion fpt or ghec %}
|
||||
```shell
|
||||
$ docker pull docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
docker pull docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
```
|
||||
{% else %}
|
||||
<!--Versioning out this "subdomain isolation enabled" line because it's the only option for GHES 2.22 so it can be misleading.-->
|
||||
@@ -245,12 +245,12 @@ $ docker pull docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
If your instance has subdomain isolation enabled:
|
||||
{% endif %}
|
||||
```shell
|
||||
$ docker pull docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
docker pull docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
```
|
||||
{% ifversion ghes %}
|
||||
If your instance has subdomain isolation disabled:
|
||||
```shell
|
||||
$ docker pull HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
docker pull HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
|
||||
```
|
||||
{% endif %}
|
||||
{% endif %}
|
||||
|
||||
@@ -163,7 +163,7 @@ subprojects {
|
||||
2. After creating your package, you can publish the package.
|
||||
|
||||
```shell
|
||||
$ gradle publish
|
||||
gradle publish
|
||||
```
|
||||
|
||||
## Using a published package
|
||||
|
||||
@@ -211,7 +211,7 @@ By default, you can only use npm packages hosted on your enterprise, and you wil
|
||||
5. Install the package.
|
||||
|
||||
```shell
|
||||
$ npm install
|
||||
npm install
|
||||
```
|
||||
|
||||
### Installing packages from other organizations
|
||||
|
||||
@@ -26,7 +26,7 @@ shortTitle: RubyGems registry
|
||||
- You must have RubyGems 2.4.1 or higher. To find your RubyGems version:
|
||||
|
||||
```shell
|
||||
$ gem --version
|
||||
gem --version
|
||||
```
|
||||
|
||||
- You must have bundler 1.6.4 or higher. To find your Bundler version:
|
||||
@@ -82,7 +82,7 @@ gem sources --add https://USERNAME:TOKEN@{% ifversion fpt or ghec %}rubygems.pkg
|
||||
To authenticate with Bundler, configure Bundler to use your {% data variables.product.pat_v1 %}, replacing USERNAME with your {% data variables.product.prodname_dotcom %} username, TOKEN with your {% data variables.product.pat_generic %}, and NAMESPACE with the name of the personal account or organization {% ifversion packages-rubygems-v2 %}to which the gem is scoped{% else %}that owns the repository containing the gem{% endif %}.{% ifversion ghes %} Replace `REGISTRY_URL` with the URL for your instance's RubyGems registry. If your instance has subdomain isolation enabled, use `rubygems.HOSTNAME`. If your instance has subdomain isolation disabled, use `HOSTNAME/_registry/rubygems`. In either case, replace HOSTNAME with the hostname of your {% data variables.product.prodname_ghe_server %} instance.{% elsif ghae %}Replace `REGISTRY_URL` with the URL for your instance's Rubygems registry, `rubygems.HOSTNAME`. Replace HOSTNAME with the hostname of {% data variables.location.product_location %}.{% endif %}
|
||||
|
||||
```shell
|
||||
$ bundle config https://{% ifversion fpt or ghec %}rubygems.pkg.github.com{% else %}REGISTRY_URL{% endif %}/NAMESPACE USERNAME:TOKEN
|
||||
bundle config https://{% ifversion fpt or ghec %}rubygems.pkg.github.com{% else %}REGISTRY_URL{% endif %}/NAMESPACE USERNAME:TOKEN
|
||||
```
|
||||
|
||||
## Publishing a package
|
||||
@@ -165,7 +165,7 @@ You can use gems from {% data variables.product.prodname_registry %} much like y
|
||||
|
||||
4. Install the package:
|
||||
```
|
||||
$ gem install GEM_NAME --version "0.1.1"
|
||||
gem install GEM_NAME --version "0.1.1"
|
||||
```
|
||||
|
||||
## Further reading
|
||||
|
||||
@@ -125,7 +125,7 @@ kramdown:
|
||||
If your theme doesn't include CSS for syntax highlighting, you can generate {% data variables.product.prodname_dotcom %}'s syntax highlighting CSS and add it to your project's `style.css` file.
|
||||
|
||||
```shell
|
||||
$ rougify style github > style.css
|
||||
rougify style github > style.css
|
||||
```
|
||||
|
||||
## Building your site locally
|
||||
|
||||
@@ -45,7 +45,7 @@ Before you can use Jekyll to create a {% data variables.product.prodname_pages %
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
1. If you don't already have a local copy of your repository, navigate to the location where you want to store your site's source files, replacing PARENT-FOLDER with the folder you want to contain the folder for your repository.
|
||||
```shell
|
||||
$ cd PARENT-FOLDER
|
||||
cd PARENT-FOLDER
|
||||
```
|
||||
1. If you haven't already, initialize a local Git repository, replacing REPOSITORY-NAME with the name of your repository.
|
||||
```shell
|
||||
@@ -113,7 +113,7 @@ Before you can use Jekyll to create a {% data variables.product.prodname_pages %
|
||||
```
|
||||
1. Push the repository to {% data variables.product.product_name %}, replacing BRANCH with the name of the branch you're working on.
|
||||
```shell
|
||||
$ git push -u origin BRANCH
|
||||
git push -u origin BRANCH
|
||||
```
|
||||
{% data reusables.pages.configure-publishing-source %}
|
||||
{% data reusables.pages.navigate-site-repo %}
|
||||
|
||||
@@ -67,11 +67,11 @@ For example, if you and another person both edited the file _styleguide.md_ on t
|
||||
```
|
||||
7. Add or stage your changes.
|
||||
```shell
|
||||
$ git add .
|
||||
git add .
|
||||
```
|
||||
8. Commit your changes with a comment.
|
||||
```shell
|
||||
$ git commit -m "Resolved merge conflict by incorporating both suggestions."
|
||||
git commit -m "Resolved merge conflict by incorporating both suggestions."
|
||||
```
|
||||
|
||||
You can now merge the branches on the command line or [push your changes to your remote repository](/get-started/using-git/pushing-commits-to-a-remote-repository) on {% data variables.product.product_name %} and [merge your changes](/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request) in a pull request.
|
||||
@@ -109,7 +109,7 @@ For example, if you edited a file, such as _README.md_, and another person remov
|
||||
|
||||
To add the removed file back to your repository:
|
||||
```shell
|
||||
$ git add README.md
|
||||
git add README.md
|
||||
```
|
||||
To remove this file from your repository:
|
||||
```shell
|
||||
|
||||
@@ -39,11 +39,11 @@ Only the user who created the pull request can give you permission to push commi
|
||||
{% endtip %}
|
||||
4. Change the current working directory to the location where you want to download the cloned directory.
|
||||
```shell
|
||||
$ cd open-source-projects
|
||||
cd open-source-projects
|
||||
```
|
||||
5. Type `git clone`, and then paste the URL you copied in Step 3.
|
||||
```shell
|
||||
$ git clone https://{% data variables.command_line.codeblock %}/USERNAME/FORK-OF-THE-REPOSITORY
|
||||
git clone https://{% data variables.command_line.codeblock %}/USERNAME/FORK-OF-THE-REPOSITORY
|
||||
```
|
||||
6. Press **Enter**. Your local clone will be created.
|
||||
```shell
|
||||
@@ -61,13 +61,13 @@ Only the user who created the pull request can give you permission to push commi
|
||||
{% endtip %}
|
||||
7. Navigate into your new cloned repository.
|
||||
```shell
|
||||
$ cd FORK-OF-THE-REPOSITORY
|
||||
cd FORK-OF-THE-REPOSITORY
|
||||
```
|
||||
7. Switch branches to the compare branch of the pull request where the original changes were made. If you navigate to the original pull request, you'll see the compare branch at the top of the pull request.
|
||||
|
||||
In this example, the compare branch is `test-branch`:
|
||||
```shell
|
||||
$ git checkout TEST-BRANCH
|
||||
git checkout TEST-BRANCH
|
||||
```
|
||||
|
||||
{% tip %}
|
||||
|
||||
@@ -71,7 +71,7 @@ Anyone can work with a previously opened pull request to continue working on it,
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
5. Fetch the reference to the pull request based on its ID number, creating a new branch in the process.
|
||||
```shell
|
||||
$ git fetch origin pull/ID/head:BRANCH_NAME
|
||||
git fetch origin pull/ID/head:BRANCH_NAME
|
||||
```
|
||||
6. Switch to the new branch that's based on this pull request:
|
||||
```shell
|
||||
|
||||
@@ -25,7 +25,7 @@ shortTitle: Configure a remote repository
|
||||
```
|
||||
3. Specify a new remote _upstream_ repository that will be synced with the fork.
|
||||
```shell
|
||||
$ git remote add upstream https://{% data variables.command_line.codeblock %}/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
|
||||
git remote add upstream https://{% data variables.command_line.codeblock %}/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
|
||||
```
|
||||
4. Verify the new upstream repository you've specified for your fork.
|
||||
```shell
|
||||
|
||||
@@ -46,7 +46,7 @@ If the changes from the upstream repository cause conflicts, {% data variables.p
|
||||
To update the remote fork from its parent, use the `gh repo sync -b BRANCHNAME` subcommand and supply your fork and branch name as arguments.
|
||||
|
||||
```shell
|
||||
$ gh repo sync owner/cli-fork -b BRANCH_NAME
|
||||
gh repo sync owner/cli-fork -b BRANCH_NAME
|
||||
```
|
||||
|
||||
If the changes from the upstream repository cause conflict then the {% data variables.product.prodname_cli %} can't sync. You can set the `-force` flag to overwrite the destination branch.
|
||||
|
||||
@@ -53,7 +53,7 @@ We strongly discourage force pushing, since this changes the history of your rep
|
||||
1. Follow the [steps above](/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message#commit-has-not-been-pushed-online) to amend the commit message.
|
||||
2. Use the `push --force-with-lease` command to force push over the old commit.
|
||||
```shell
|
||||
$ git push --force-with-lease origin EXAMPLE-BRANCH
|
||||
git push --force-with-lease origin EXAMPLE-BRANCH
|
||||
```
|
||||
|
||||
**Changing the message of older or multiple commit messages**
|
||||
@@ -102,7 +102,7 @@ If you need to amend the message for multiple commits or an older commit, you ca
|
||||
5. In each resulting commit file, type the new commit message, save the file, and close it.
|
||||
6. When you're ready to push your changes to GitHub, use the push --force command to force push over the old commit.
|
||||
```shell
|
||||
$ git push --force origin EXAMPLE-BRANCH
|
||||
git push --force origin EXAMPLE-BRANCH
|
||||
```
|
||||
|
||||
For more information on interactive rebase, see "[Interactive mode](https://git-scm.com/docs/git-rebase#_interactive_mode)" in the Git manual.
|
||||
|
||||
@@ -36,7 +36,7 @@ There are several possible explanations:
|
||||
Your local repository may not have the commit yet. To get information from your remote repository to your local clone, use `git fetch`:
|
||||
|
||||
```shell
|
||||
$ git fetch REMOTE
|
||||
git fetch REMOTE
|
||||
```
|
||||
|
||||
This safely copies information from the remote repository to your local clone without making any changes to the files you have checked out.
|
||||
|
||||
@@ -40,14 +40,14 @@ After you rename a branch in a repository on {% data variables.product.product_n
|
||||
From the local clone of the repository on a computer, run the following commands to update the name of the default branch.
|
||||
|
||||
```shell
|
||||
$ git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
|
||||
$ git fetch origin
|
||||
$ git push origin NEW-BRANCH-NAME
|
||||
$ git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
|
||||
$ git remote set-head origin -a
|
||||
git branch -m OLD-BRANCH-NAME NEW-BRANCH-NAME
|
||||
git fetch origin
|
||||
git push origin NEW-BRANCH-NAME
|
||||
git branch -u origin/NEW-BRANCH-NAME NEW-BRANCH-NAME
|
||||
git remote set-head origin -a
|
||||
```
|
||||
|
||||
Optionally, run the following command to remove tracking references to the old branch name.
|
||||
```
|
||||
$ git remote prune origin
|
||||
git remote prune origin
|
||||
```
|
||||
|
||||
@@ -31,17 +31,17 @@ Before you can push the original repository to your new copy, or _mirror_, of th
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Create a bare clone of the repository.
|
||||
```shell
|
||||
$ git clone --bare https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/OLD-REPOSITORY.git
|
||||
git clone --bare https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/OLD-REPOSITORY.git
|
||||
```
|
||||
3. Mirror-push to the new repository.
|
||||
```shell
|
||||
$ cd OLD-REPOSITORY.git
|
||||
$ git push --mirror https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/NEW-REPOSITORY.git
|
||||
cd OLD-REPOSITORY.git
|
||||
git push --mirror https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/NEW-REPOSITORY.git
|
||||
```
|
||||
4. Remove the temporary local repository you created earlier.
|
||||
```shell
|
||||
$ cd ..
|
||||
$ rm -rf OLD-REPOSITORY.git
|
||||
cd ..
|
||||
rm -rf OLD-REPOSITORY.git
|
||||
```
|
||||
|
||||
## Mirroring a repository that contains {% data variables.large_files.product_name_long %} objects
|
||||
@@ -49,28 +49,28 @@ Before you can push the original repository to your new copy, or _mirror_, of th
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Create a bare clone of the repository. Replace the example username with the name of the person or organization who owns the repository, and replace the example repository name with the name of the repository you'd like to duplicate.
|
||||
```shell
|
||||
$ git clone --bare https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/OLD-REPOSITORY.git
|
||||
git clone --bare https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/OLD-REPOSITORY.git
|
||||
```
|
||||
3. Navigate to the repository you just cloned.
|
||||
```shell
|
||||
$ cd OLD-REPOSITORY.git
|
||||
cd OLD-REPOSITORY.git
|
||||
```
|
||||
4. Pull in the repository's {% data variables.large_files.product_name_long %} objects.
|
||||
```shell
|
||||
$ git lfs fetch --all
|
||||
git lfs fetch --all
|
||||
```
|
||||
5. Mirror-push to the new repository.
|
||||
```shell
|
||||
$ git push --mirror https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/NEW-REPOSITORY.git
|
||||
git push --mirror https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/NEW-REPOSITORY.git
|
||||
```
|
||||
6. Push the repository's {% data variables.large_files.product_name_long %} objects to your mirror.
|
||||
```shell
|
||||
$ git lfs push --all https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git
|
||||
git lfs push --all https://github.com/EXAMPLE-USER/NEW-REPOSITORY.git
|
||||
```
|
||||
7. Remove the temporary local repository you created earlier.
|
||||
```shell
|
||||
$ cd ..
|
||||
$ rm -rf OLD-REPOSITORY.git
|
||||
cd ..
|
||||
rm -rf OLD-REPOSITORY.git
|
||||
```
|
||||
|
||||
## Mirroring a repository in another location
|
||||
@@ -80,19 +80,19 @@ If you want to mirror a repository in another location, including getting update
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
2. Create a bare mirrored clone of the repository.
|
||||
```shell
|
||||
$ git clone --mirror https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/REPOSITORY-TO-MIRROR.git
|
||||
git clone --mirror https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/REPOSITORY-TO-MIRROR.git
|
||||
```
|
||||
3. Set the push location to your mirror.
|
||||
```shell
|
||||
$ cd REPOSITORY-TO-MIRROR
|
||||
$ git remote set-url --push origin https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/MIRRORED
|
||||
cd REPOSITORY-TO-MIRROR
|
||||
git remote set-url --push origin https://{% data variables.command_line.codeblock %}/EXAMPLE-USER/MIRRORED
|
||||
```
|
||||
As with a bare clone, a mirrored clone includes all remote branches and tags, but all local references will be overwritten each time you fetch, so it will always be the same as the original repository. Setting the URL for pushes simplifies pushing to your mirror.
|
||||
|
||||
4. To update your mirror, fetch updates and push.
|
||||
```shell
|
||||
$ git fetch -p origin
|
||||
$ git push --mirror
|
||||
git fetch -p origin
|
||||
git push --mirror
|
||||
```
|
||||
{% ifversion fpt or ghec %}
|
||||
## Further reading
|
||||
|
||||
@@ -25,7 +25,7 @@ For more information on project sites, see "[AUTOTITLE](/pages/getting-started-w
|
||||
In addition to redirecting web traffic, all `git clone`, `git fetch`, or `git push` operations targeting the previous location will continue to function as if made on the new location. However, to reduce confusion, we strongly recommend updating any existing local clones to point to the new repository URL. You can do this by using `git remote` on the command line:
|
||||
|
||||
```shell
|
||||
$ git remote set-url origin NEW_URL
|
||||
git remote set-url origin NEW_URL
|
||||
```
|
||||
|
||||
For more information, see "[AUTOTITLE](/get-started/getting-started-with-git/managing-remote-repositories)."
|
||||
|
||||
@@ -51,7 +51,7 @@ When you transfer a repository, its issues, pull requests, wiki, stars, and watc
|
||||
- All links to the previous repository location are automatically redirected to the new location. When you use `git clone`, `git fetch`, or `git push` on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL. You can do this by using `git remote` on the command line:
|
||||
|
||||
```shell
|
||||
$ git remote set-url origin NEW_URL
|
||||
git remote set-url origin NEW_URL
|
||||
```
|
||||
|
||||
{% warning %}
|
||||
|
||||
@@ -52,7 +52,7 @@ Many files can be [renamed directly on {% data variables.product.product_name %}
|
||||
{% data reusables.command_line.switching_directories_procedural %}
|
||||
3. Rename the file, specifying the old file name and the new name you'd like to give the file. This will stage your change for commit.
|
||||
```shell
|
||||
$ git mv OLD-FILENAME NEW-FILENAME
|
||||
git mv OLD-FILENAME NEW-FILENAME
|
||||
```
|
||||
4. Use `git status` to check the old and new file names.
|
||||
```shell
|
||||
|
||||
@@ -50,12 +50,12 @@ If there are existing files in your repository that you'd like to use {% data va
|
||||
|
||||
4. Add a file to the repository matching the extension you've associated:
|
||||
```shell
|
||||
$ git add path/to/file.psd
|
||||
git add path/to/file.psd
|
||||
```
|
||||
5. Commit the file and push it to {% data variables.product.product_name %}:
|
||||
```shell
|
||||
$ git commit -m "add file.psd"
|
||||
$ git push
|
||||
git commit -m "add file.psd"
|
||||
git push
|
||||
```
|
||||
You should see some diagnostic information about your file upload:
|
||||
```shell
|
||||
|
||||
@@ -25,7 +25,7 @@ shortTitle: Install Git LFS
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
3. Change the current working directory into the folder you downloaded and unzipped.
|
||||
```shell
|
||||
$ cd ~/Downloads/git-lfs-1.X.X
|
||||
cd ~/Downloads/git-lfs-1.X.X
|
||||
```
|
||||
{% note %}
|
||||
|
||||
@@ -85,7 +85,7 @@ shortTitle: Install Git LFS
|
||||
{% data reusables.command_line.open_the_multi_os_terminal %}
|
||||
3. Change the current working directory into the folder you downloaded and unzipped.
|
||||
```shell
|
||||
$ cd ~/Downloads/git-lfs-1.X.X
|
||||
cd ~/Downloads/git-lfs-1.X.X
|
||||
```
|
||||
{% note %}
|
||||
|
||||
|
||||
@@ -30,11 +30,11 @@ shortTitle: Remove files
|
||||
1. Remove the files from the repository's Git history using either the `filter-repo` command or BFG Repo-Cleaner. For detailed information on using these, see "[AUTOTITLE](/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository)."
|
||||
2. Optionally, to uninstall {% data variables.large_files.product_name_short %} in the repository, run:
|
||||
```shell
|
||||
$ git lfs uninstall
|
||||
git lfs uninstall
|
||||
```
|
||||
For {% data variables.large_files.product_name_short %} versions below 1.1.0, run:
|
||||
```shell
|
||||
$ git lfs uninit
|
||||
git lfs uninit
|
||||
```
|
||||
|
||||
## {% data variables.large_files.product_name_short %} objects in your repository
|
||||
|
||||
@@ -19,9 +19,9 @@ To resolve the error message, you must reinstall your local {% data variables.la
|
||||
1. Open Terminal.
|
||||
2. Reinstall {% data variables.large_files.product_name_short %}.
|
||||
```shell
|
||||
$ git lfs install
|
||||
git lfs install
|
||||
```
|
||||
3. Push all referenced {% data variables.large_files.product_name_short %} files.
|
||||
```shell
|
||||
$ git lfs push --all origin
|
||||
git lfs push --all origin
|
||||
```
|
||||
|
||||
@@ -323,7 +323,7 @@ To view a fully interactive version of your Jupyter Notebook, you can set up a n
|
||||
If you're having trouble rendering Jupyter Notebook files in static HTML, you can convert the file locally on the command line by using the [`nbconvert` command](https://github.com/jupyter/nbconvert):
|
||||
|
||||
```shell
|
||||
$ jupyter nbconvert --to html NOTEBOOK-NAME.ipynb
|
||||
jupyter nbconvert --to html NOTEBOOK-NAME.ipynb
|
||||
```
|
||||
|
||||
### Further reading about Jupyter Notebook
|
||||
|
||||
@@ -29,13 +29,13 @@ You need to pass your [{% ifversion enterprise-management-console-multi-user-aut
|
||||
Use the `api_key` parameter to send this token with each request. For example:
|
||||
|
||||
```shell
|
||||
$ curl -L 'https://HOSTNAME:ADMIN-PORT/setup/api?api_key=YOUR_PASSWORD'
|
||||
curl -L 'https://HOSTNAME:ADMIN-PORT/setup/api?api_key=YOUR_PASSWORD'
|
||||
```
|
||||
|
||||
You can also use standard HTTP authentication to send this token. For example:
|
||||
|
||||
```shell
|
||||
$ curl -L -u "api_key:YOUR_PASSWORD" 'https://HOSTNAME:ADMIN-PORT/setup/api'
|
||||
curl -L -u "api_key:YOUR_PASSWORD" 'https://HOSTNAME:ADMIN-PORT/setup/api'
|
||||
```
|
||||
|
||||
{% ifversion enterprise-management-console-multi-user-auth %}
|
||||
@@ -47,7 +47,7 @@ $ curl -L -u "api_key:YOUR_PASSWORD" 'https://HOSTNAME:ADMIN-PORT/setup/api'
|
||||
To authenticate with the password for a {% data variables.enterprise.management_console %} user account, use standard HTTP authentication. In the following example, replace YOUR_USER_NAME and YOUR_PASSWORD with the account's user name and password.
|
||||
|
||||
```shell
|
||||
$ curl -L -u "YOUR_USER_NAME:YOUR_PASSWORD" 'https://HOSTNAME:ADMIN-PORT/setup/api'
|
||||
curl -L -u "YOUR_USER_NAME:YOUR_PASSWORD" 'https://HOSTNAME:ADMIN-PORT/setup/api'
|
||||
```
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -25,7 +25,7 @@ The {% data variables.product.prodname_ghe_server %} release notes will state wh
|
||||
You should use the `X-GitHub-Api-Version` header to specify an API version. For example:
|
||||
|
||||
```shell
|
||||
$ curl {% data reusables.rest-api.version-header %} https://api.github.com/zen
|
||||
curl {% data reusables.rest-api.version-header %} https://api.github.com/zen
|
||||
```
|
||||
|
||||
Requests without the `X-GitHub-Api-Version` header will default to use the `{{ initialRestVersioningReleaseDate }}` version.
|
||||
|
||||
@@ -157,7 +157,7 @@ specified as a segment in the path can be passed as an HTTP query string
|
||||
parameter:
|
||||
|
||||
```shell
|
||||
$ curl -i "{% data variables.product.api_url_pre %}/repos/vmg/redcarpet/issues?state=closed"
|
||||
curl -i "{% data variables.product.api_url_pre %}/repos/vmg/redcarpet/issues?state=closed"
|
||||
```
|
||||
|
||||
In this example, the 'vmg' and 'redcarpet' values are provided for the `:owner`
|
||||
@@ -168,7 +168,7 @@ For `POST`, `PATCH`, `PUT`, and `DELETE` requests, parameters not included in th
|
||||
with a Content-Type of 'application/json':
|
||||
|
||||
```shell
|
||||
$ curl -i --header "Authorization: Bearer YOUR-TOKEN" -d '{"scopes":["repo_deployment"]}' {% data variables.product.api_url_pre %}/authorizations
|
||||
curl -i --header "Authorization: Bearer YOUR-TOKEN" -d '{"scopes":["repo_deployment"]}' {% data variables.product.api_url_pre %}/authorizations
|
||||
```
|
||||
|
||||
## Root endpoint
|
||||
@@ -651,7 +651,7 @@ These timestamps look something like `2014-02-27T15:05:06+01:00`. Also see [this
|
||||
It is possible to supply a `Time-Zone` header which defines a timezone according to the [list of names from the Olson database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).
|
||||
|
||||
```shell
|
||||
$ curl -H "Time-Zone: Europe/Amsterdam" -X POST {% data variables.product.api_url_pre %}/repos/github-linguist/linguist/contents/new_file.md
|
||||
curl -H "Time-Zone: Europe/Amsterdam" -X POST {% data variables.product.api_url_pre %}/repos/github-linguist/linguist/contents/new_file.md
|
||||
```
|
||||
|
||||
This means that we generate a timestamp for the moment your API call is made in the timezone this header defines. For example, the API to manage contents generates a git commit for each addition or change and uses the current time as the timestamp. For more information, see "[AUTOTITLE](/rest/repos#contents)." This header will determine the timezone used for generating that current timestamp.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user