Подготовка к работе с заданиями
Все, что написано на этой странице нужно выполнить только один раз в начале настройки. Если вы работаете на нескольких vm/машинах, установку скрипта ptest и создание переменной окружения надо выполнить на каждой.
Скрипт ptest
После выполнения задания, его надо:
Установка скрипта ptest
Надо перейти в свой репозиторий, например (пишите имя своего репозитория):
Затем внутри репозитория дать команду
Это установит модуль и даст возможность вызывать его в любом каталоге по слову ptest.
Токен Github
Для сдачи заданий на проверку, надо сгенерировать токен Github. Это специальное значение, которое позволяет дать только конкретные права для скрипта, который использует токен.
Создать токен нужно по ссылке
Нажать “Generate new token”
Выбрать имя и нажать галочку “repo”, чтобы дать права на работу с репозиториями:
Внизу нажать “Generate token”:
Затем скопировать token:
И сохранить его в переменной окружения GITHUB_TOKEN.
Для linux
Нужно записать токен в файл
/.bashrc в таком виде:
Если у Вас не bash, как сделать переменную окружения, надо найти самостоятельно.
Для Mac
Для начала надо проверить какой shell используется. Для этого в командной строке надо дать команду:
/.bash_profile в таком виде:
/.zshrc в таком виде:
Для Windows
Сообщение о проверенных заданиях
После сдачи заданий на проверку, вам надо как-то получать оповещение, когда задания проверены. Для этого я пишу комментарий на github, после проверки.
Чтобы вам приходило оповещение про проверку заданий (оставленный комментарий), вам нужно следить за репозиторием. Чтобы это включить, надо нажать кнопку “Watch” в вашем репозитории и выбрать вариант “All activity”.
Выбрать “All activity”
После этого вам на почту будут приходить оповещения, когда я напишу комментарий.
Оповещения буду приходить на тот email, который вы указывали при регистрации на github.
Аутентификация с GitHub с помощью токена
Я пытаюсь пройти аутентификацию в GitHub, используя токен личного доступа. В файлах справки на github говорится об использовании метода cURL для аутентификации ( https://help.github.com/articles/creating-an-access-token-for-command-line-use ). Я пробовал это, но все еще не могу нажать на GitHub. Обратите внимание, я пытаюсь выполнить отправку с неаутентифицированного сервера (Travis-CI).
Этот код вызывает ошибки:
удаленный: анонимный доступ к scuzzlebuzzle / ol3-1.git запрещен.
Ваша curl команда совершенно неверна. Вы должны использовать следующие
Кроме того, это не разрешает вашему компьютеру клонировать репозиторий, если он на самом деле является частным. (Однако взгляд показывает, что это не так.) Обычно вы делаете следующее:
Это добавит ваши учетные данные на пульт, созданный при клонировании репозитория. Однако, к сожалению, вы не можете контролировать, как Трэвис клонирует ваш репозиторий, поэтому вам нужно отредактировать пульт таким образом.
Это исправит ваш проект для использования пульта дистанционного управления со встроенными учетными данными.
Как ни смешно, в статье рассказывается, как его создать, но совершенно не говорится, что с ним делать. Примерно через час изучения документации и Stack Overflow я наконец нашел ответ:
(@YMHuang направил меня на правильный путь с помощью ссылки на документацию.)
Если вы хотите ограничить доступ (с немного большей работой!), Вы можете использовать ключи развертывания GitHub в сочетании с зашифрованными полями yaml Travis.
Сначала сгенерируйте вызванный ключ развертывания RSA (через ssh-keygen ) my_key и добавьте его в качестве ключа развертывания в настройки репозитория github.
Примечание: последняя строка предварительно заполняет ключ RSA github, что позволяет избежать необходимости принимать вручную во время подключения.
Automatic token authentication
In this article
GitHub provides a token that you can use to authenticate on behalf of GitHub Actions.
About the GITHUB_TOKEN secret
At the start of each workflow run, GitHub automatically creates a unique GITHUB_TOKEN secret to use in your workflow. You can use the GITHUB_TOKEN to authenticate in a workflow run.
Before each job begins, GitHub fetches an installation access token for the job. The token expires when the job is finished.
The token is also available in the github.token context. For more information, see «Contexts.»
Using the GITHUB_TOKEN in a workflow
Example 1: passing the GITHUB_TOKEN as an input
This example workflow uses the labeler action, which requires the GITHUB_TOKEN as the value for the repo-token input parameter:
Example 2: calling the REST API
You can use the GITHUB_TOKEN to make authenticated API calls. This example workflow creates an issue using the GitHub REST API:
Permissions for the GITHUB_TOKEN
For information about the API endpoints GitHub Apps can access with each permission, see «GitHub App Permissions.»
The following table shows the permissions granted to the GITHUB_TOKEN by default. People with admin permissions to an enterprise, organization, or repository, can set the default permissions to be either permissive or restricted. For information on how to set the default permissions for the GITHUB_TOKEN for your enterprise, organization, or repository, see «Enforcing policies for GitHub Actions in your enterprise,» «Disabling or limiting GitHub Actions for your organization,» or «Managing GitHub Actions settings for a repository.»
| Scope | Default access (permissive) | Default access (restricted) | Maximum access by forked repos |
|---|---|---|---|
| actions | read/write | none | read |
| checks | read/write | none | read |
| contents | read/write | read | read |
| deployments | read/write | none | read |
| id-token | read/write | none | read |
| issues | read/write | none | read |
| metadata | read | read | read |
| packages | read/write | none | read |
| pull requests | read/write | none | read |
| repository projects | read/write | none | read |
| security events | read/write | none | read |
| statuses | read/write | none | read |
Modifying the permissions for the GITHUB_TOKEN
You can see the permissions that GITHUB_TOKEN had for a specific job in the «Set up job» section of the workflow run log. For more information, see «Using workflow run logs.»
You can use the permissions key in your workflow file to modify permissions for the GITHUB_TOKEN for an entire workflow or for individual jobs. This allows you to configure the minimum required permissions for a workflow or job. When the permissions key is used, all unspecified permissions are set to no access, with the exception of the metadata scope, which always gets read access.
You can use the permissions key to add and remove read permissions for forked repositories, but typically you can’t grant write access. The exception to this behavior is where an admin user has selected the Send write tokens to workflows from pull requests option in the GitHub Actions settings. For more information, see «Managing GitHub Actions settings for a repository.»
The two workflow examples earlier in this article show the permissions key being used at the workflow level, and at the job level. In Example 1 the two permissions are specified for the entire workflow. In Example 2 write access is granted for one scope for a single job.
For full details of the permissions key, see «Workflow syntax for GitHub Actions.»
How the permissions are calculated for a workflow job
The permissions for the GITHUB_TOKEN are initially set to the default setting for the enterprise, organization, or repository. If the default is set to the restricted permissions at any of these levels then this will apply to the relevant repositories. For example, if you choose the restricted default at the organization level then all repositories in that organization will use the restricted permissions as the default. The permissions are then adjusted based on any configuration within the workflow file, first at the workflow level and then at the job level. Finally, if the workflow was triggered by a pull request from a forked repository, and the Send write tokens to workflows from pull requests setting is not selected, the permissions are adjusted to change any write permissions to read only.
Granting additional permissions
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
Creating a personal access token
In this article
You should create a personal access token to use in place of a password with the command line or with the API.
Personal access tokens (PATs) are an alternative to using passwords for authentication to GitHub when using the GitHub API or the command line.
If you want to use a PAT to access resources owned by an organization that uses SAML SSO, you must authorize the PAT. For more information, see «About authentication with SAML single sign-on» and «Authorizing a personal access token for use with SAML single sign-on» in the GitHub Enterprise Cloud documentation.
As a security precaution, GitHub automatically removes personal access tokens that haven’t been used in a year. To provide additional security, we highly recommend adding an expiration to your personal access tokens.
Verify your email address, if it hasn’t been verified yet.
In the upper-right corner of any page, click your profile photo, then click Settings. 
In the left sidebar, click Developer settings. 
In the left sidebar, click Personal access tokens. 
Click Generate new token. 
Give your token a descriptive name. 
To give your token an expiration, select the Expiration drop-down menu, then click a default or use the calendar picker. 
Select the scopes, or permissions, you’d like to grant this token. To use your token to access repositories from the command line, select repo.
Click Generate token. 
Warning: Treat your tokens like passwords and keep them secret. When working with the API, use tokens as environment variables instead of hardcoding them into your programs.
To use your token to authenticate to an organization that uses SAML single sign-on, authorize the token. For more information, see «Authorizing a personal access token for use with SAML single sign-on» in the GitHub Enterprise Cloud documentation.
Using a token on the command line
Once you have a token, you can enter it instead of your password when performing Git operations over HTTPS.
For example, on the command line you would enter the following:
Personal access tokens can only be used for HTTPS Git operations. If your repository uses an SSH remote URL, you will need to switch the remote from SSH to HTTPS.
If you are not prompted for your username and password, your credentials may be cached on your computer. You can update your credentials in the Keychain to replace your old password with the token.
Instead of manually entering your PAT for every HTTPS Git operation, you can cache your PAT with a Git client. Git will temporarily store your credentials in memory until an expiry interval has passed. You can also store the token in a plain text file that Git can read before every request. For more information, see «Caching your GitHub credentials in Git.»
About authentication to GitHub
In this article
You can securely access your account’s resources by authenticating to GitHub Enterprise Server, using different credentials depending on where you authenticate.
About authentication to GitHub
To keep your account secure, you must authenticate before you can access certain resources on GitHub. When you authenticate to GitHub, you supply or confirm credentials that are unique to you to prove that you are exactly who you declare to be.
You can access your resources in GitHub in a variety of ways: in the browser, via GitHub Desktop or another desktop application, with the API, or via the command line. Each way of accessing GitHub supports different modes of authentication.
Authenticating in your browser
You can authenticate to GitHub in your browser in different ways.
If you’re a member of an enterprise with managed users, you will authenticate to GitHub in your browser using your IdP. For more information, see «Authenticating as a managed user» in the GitHub Enterprise Cloud documentation. If you’re not a member of an enterprise with managed users, you will authenticate using your browser on GitHub.com.
Username and password only
Two-factor authentication (2FA) (recommended)
Authenticating with GitHub Desktop
You can authenticate with GitHub Desktop using your browser. For more information, see «Authenticating to GitHub.»
Authenticating with the API
You can authenticate with the API in different ways.
Authenticating with the command line
You can access repositories on GitHub from the command line in two ways, HTTPS and SSH, and both have a different way of authenticating. The method of authenticating is determined based on whether you choose an HTTPS or SSH remote URL when you clone the repository. For more information about which way to access, see «About remote repositories.»
You can work with all repositories on GitHub over HTTPS, even if you are behind a firewall or proxy.
If you authenticate without GitHub CLI, you must authenticate with a personal access token. When Git prompts you for your password, enter your personal access token (PAT) instead. Password-based authentication for Git has been removed, and using a PAT is more secure. For more information, see «Creating a personal access token.» Every time you use Git to authenticate with GitHub, you’ll be prompted to enter your credentials to authenticate with GitHub, unless you cache them a credential helper.
You can work with all repositories on GitHub over SSH, although firewalls and proxys might refuse to allow SSH connections.
If you authenticate without GitHub CLI, you will need to generate an SSH public/private keypair on your local machine and add the public key to your account on GitHub.com. For more information, see «Generating a new SSH key and adding it to the ssh-agent.» Every time you use Git to authenticate with GitHub, you’ll be prompted to enter your SSH key passphrase, unless you’ve stored the key.
Authorizing for SAML single sign-on
To use a personal access token or SSH key to access resources owned by an organization that uses SAML single sign-on, you must also authorize the personal token or SSH key. For more information, see «Authorizing a personal access token for use with SAML single sign-on» or «Authorizing an SSH key for use with SAML single sign-on» in the GitHub Enterprise Cloud documentation.
GitHub’s token formats
GitHub issues tokens that begin with a prefix to indicate the token’s type.
| Token type | Prefix | More information |
|---|---|---|
| Personal access token | ghp_ | «Creating a personal access token» |
| OAuth access token | gho_ | «Authorizing OAuth Apps» |
| User-to-server token for a GitHub App | ghu_ | «Identifying and authorizing users for GitHub Apps» |
| Server-to-server token for a GitHub App | ghs_ | «Authenticating with GitHub Apps» |
| Refresh token for a GitHub App | ghr_ | «Refreshing user-to-server access tokens» |
Help us make these docs great!
All GitHub docs are open source. See something that’s wrong or unclear? Submit a pull request.
