* Avoid white, it is unreadable on light themes (#1295)
* remove ', ConsoleColor.White' from banner
* remove ', ConsoleColor.White' from prompt
* cleanups
* Update error to say 'uninstall' not 'unconfigure'
* Say uninstall service in *nix config error msgs
Co-authored-by: Ferenc Hammerl <[email protected]>
* Trim pwsh special chars when masking secrets
* Add pwsh valueEncoder
* Explain regex
* Update ValueEncoders.cs
* Add tests for pwsh color codes in secrets
* Formatting
* Group tests into theories
* Split secret on PS chars and mask for them
* Clean up comments
* Remove unused unittest
* Rename escape methods
* Use flags in svc creation script
* Refactor regex and add comments
* Fix indentation and typo in user matching
* Consistency use flags in automation scripts
* Update documentation to reflect new usage
* Make example more readable
* Remove test echos from script
* Remove test echo
* Format scripts and remove test script
* Remove tar
* Use getopts and single letter flags
* Update docs to show flag usage
* Update usage of create svc
* Revert svc to not use flags
* Revert delete script
* Update docs
* Readd deleted comments
* Add Notice Command
* Add Feature Flag For Enhanced Annotations
* Fix tests
* Add validation for columns and lines
* Fix order to match service
* Remove console.write
* Make Validation Better
* Cleanup
* Handle empty/whitespace strings
* Add more validation for line/column ranges
* Make Validation Debug, Not Throw
* Change casing to 🐫 from 🐍
* Give notice a well known tag
* Cleanup
* Sanitize invalid commands rather than fail
* fix some typos in docs of JobDispatcher
* one more typo
* Update src/Runner.Listener/JobDispatcher.cs
Co-authored-by: Ferenc Hammerl <[email protected]>
* Stop ignoring .vscode (launch scripts)
* Check in launch scripts for config and run
This can cause an issue with existing launch configuration on the machines of contributors.
* Improve error msg when runner is not configured
* Unignore .vscode/launch and tasks only
* Remove stopAtEntry and add eof newline
* Remove Runner.Listener from error message
* Rename tasks and run configs
* Ignore BuildConstants.cs
* Use better error msg
* Explain development steps in depth
* Add launch config to directly debug worker
* Update docs with VS Code tips
* Remove auto-generated comments
* Fix link to quickstart in vscode.md
* Remove ':' from link to quickstart
* Revert "Ignore BuildConstants.cs"
This reverts commit 0f13922a87.
* Replace `.sh` with `.(sh/cmd)` in docs
* Wait for debugger to attach in Worker
Only if GITHUB_ACTIONS_RUNNER_ATTACH_DEBUGGER is set
* Only wait if env variable parses to boolean 'true'
* Add 30s timeout to the wait
* Clean up leftover line
* Decrease wait to 20s
* Use ConvertToBoolean isntead of TryParse
From February 2021, in order to provide feedback on pull requests, Code Scanning workflows must be configured with both `push` and `pull_request` triggers. This is because Code Scanning compares the results from a pull request against the results for the base branch to tell you only what has changed between the two.
Early in the beta period we supported displaying results on pull requests for workflows with only `push` triggers, but have discontinued support as this proved to be less robust.
See https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#scanning-pull-requests for more information on how best to configure your Code Scanning workflows.
During job run we may fail to resolve actions download info, and this
stack is fully controlled by GitHub actions so it should be counted as
infrastructure failure instead of user failure.
* Use FIPS compliant crypto when required
* Comment cleanup
* Store OAuth signing scheme in credentialData instead of runner setting
Add encryption scheme for job message encyption key to session
Further cleanup of unused crypto code
* Update windows rsa key manager to use crossplat dotnet RSA api
* Undo unneeded ConfigurationManager change
* add `workflow_dispatch`
* Add an environment variable to indicate which repository the currently running Action came from.
* Expose the Action ref as well.
* Move setting `github.action_repository` and `github.action_ref` to `ActionRunner.cs`.
* Don't set `action_repository` and `action_ref` for local Actions.
Co-authored-by: Tingluo Huang <[email protected]>
remove 3 "redundant" text and put one text for DRY.
and developers always forget `sudo` and annoying `Need to run with sudo privilege` message.
so, add first.
* Change `ping .. > nul` to `sleep`
The filename `nul` is a Windows-ism that causes the update script to
create such a file in the current working directory. The `ping`
utility is also an dependency not installed by
`installdependencies.sh`, so it seemed easier to change it to the
standard `sleep` command.
* Update dotnet-install script as requested by test
* Update dotnet-install.ps1
Co-authored-by: Tingluo Huang <[email protected]>
* Unify apt/apt-get logic
The previous logic was buggy in that it tried to use `apt` in the `apt-get` branch after deciding that `apt` was unavailable...
* Prefer apt-get over apt
apt does not have a stable cli and using it from scripts yields annoying messages
* Improve English for missing apt-get & apt case
* Fix apt-get/apt fallback behavior for $ patterns
If there's a `$` in the apt install pattern, it will not fail if it selects a thing and decides it isn't interested in installing it.
* Fix spelling of libssl
This change updates the .NET Core SDK used by the Actions Runner to
version 3.1.302 to address the issues that are caused by the following issue:
https://github.com/dotnet/runtime/issues/13475
See #574 for more information.
Fixes#574
The runner is the application that runs a job from a GitHub Actions workflow. It is used by GitHub Actions in the [hosted virtual environments](https://github.com/actions/virtual-environments), or you can [self-host the runner](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-self-hosted-runners) in your own environment.
- Proxy support is required for some enterprises and organizations to start using their own selfhosted runners
- While there is not a standard convention, many applications support setting proxies via the environmental variables `http_proxy`, `https_proxy`, `no_proxy`, such as curl, wget, perl, python, docker, git, R, ect
- Proxy support is required for some enterprises and organizations to start using their own self-hosted runners
- While there is not a standard convention, many applications support setting proxies via the environment variables `http_proxy`, `https_proxy`, `no_proxy`, such as curl, wget, perl, python, docker, git, and R
- Some of these applications use `HTTPS_PROXY` versus `https_proxy`, but most understand or primarily support the lowercase variant
## Decision
We will update the Runner to use the conventional environment variables for proxies: `http_proxy`, `https_proxy` and `no_proxy` if they are set.
We will update the Runner to use the conventional environment variables for proxies: `http_proxy`, `https_proxy`, and `no_proxy` if they are set.
These are described in detail below:
-`https_proxy` a proxy URL for all https traffic. It may contain basic authentication credentials. For example:
- http://proxy.com
@@ -22,20 +22,20 @@ These are described in detail below:
- http://proxy.com
- http://127.0.0.1:8080
- http://user:password@proxy.com
-`no_proxy` a commaseperated list of hosts that should not use the proxy. An optional port may be specified
-`no_proxy` a comma-separated list of hosts that should not use the proxy. An optional port may be specified. For example:
-`google.com`
-`yahoo.com:443`
-`google.com,bing.com`
We won't use `http_proxy` for https traffic when `https_proxy` is not set, this behavior lines up with any libcurl based tools (curl, git) and wget.
Otherwise action authors and workflow users need to adjust to differences between the runner proxy convention, and tools used by their actions and scripts.
Otherwise, action authors and workflow users need to adjust to differences between the runner proxy convention, and tools used by their actions and scripts.
Example:
Customer set `http_proxy=http://127.0.0.1:8888` and configure the runner against `https://github.com/owner/repo`, with the `https_proxy` -> `http_proxy` fallback, the runner will connect to server without any problem. However, if user runs `git push` to `https://github.com/owner/repo`, `git` won't use the proxy since it require `https_proxy` to be set for any https traffic.
Customer sets`http_proxy=http://127.0.0.1:8888` and configures the runner against `https://github.com/owner/repo`, with the `https_proxy` -> `http_proxy` fallback, the runner will connect to the server without any problem. However, if a user runs `git push` to `https://github.com/owner/repo`, `git` won't use the proxy since it requires`https_proxy` to be set for any https traffic.
> `golang`, `node.js` and other dev tools from the linux community use `http_proxy` for both http and https traffic base on my research.
> `golang`, `node.js`, and other dev tools from the Linux community use `http_proxy` for both http and https traffic based on my research.
A majority of our users are using Linux where these variables are commonly required to be set by various programs. By reading these values, we simplify the process for selfhosted runners to set up proxy, and expose it in a way users are already familiar with.
A majority of our users are using Linux where these variables are commonly required to be set by various programs. By reading these values, we simplify the process for self-hosted runners to set up a proxy and expose it in a way users are already familiar with.
A password provided for a proxy will be masked in the logs.
@@ -43,19 +43,19 @@ We will support the lowercase and uppercase variants, with lowercase taking prio
### No Proxy Format
While exact implementations are different per application on handle`no_proxy` env, most applications accept a commaseparated list of hosts. Some accept wildcard characters (*). We are going to do exact case-insentive matches, and not support wildcards at this time.
While exact implementations are different per application on handling`no_proxy` env, most applications accept a comma-separated list of hosts. Some accept wildcard characters (`*`). We are going to do exact case-insensitive matches, and not support wildcards at this time.
For example:
- example.com will match example.com, foo.example.com, foo.bar.example.com
- foo.example.com will match bar.foo.example.com and foo.example.com
-`example.com` will match `example.com`, `foo.example.com`, and `foo.bar.example.com`
-`foo.example.com` will match `bar.foo.example.com` and `foo.example.com`
We will not support IP addresses for `no_proxy`, only hostnames.
## Consequences
1. Enterprises and organizations needing proxy support will be able to embrace selfhosted runners
2. Users will need to set these environmental variables before configuring the runner in order to use a proxy when configuring
3. The runner will read from the environmental variables during config and runtime and use the provided proxy if it exists
4. Users may need to pass these environmental variables into other applications if they do not natively take these variables
5. Action authors may need to update their workflows to react to the these environment variables
6. We will document the way of setting environmental variables for runners using the environmental variables and how the runner uses them
7. Like all other secrets, users will be able to relatively easily figure out proxy password if they can modify a workflow file running on a selfhosted machine
1. Enterprises and organizations needing proxy support will be able to embrace self-hosted runners
2. Users will need to set these environment variables before configuring the runner in order to use a proxy when configuring
3. The runner will read from the environment variables during config and runtime and use the provided proxy if it exists
4. Users may need to pass these environment variables into other applications if they do not natively take these variables
5. Action authors may need to update their workflows to react to these environment variables
6. We will document the way of setting environment variables for runners using the environment variables and how the runner uses them
7. Like all other secrets, users will be able to relatively easily figure out the proxy password if they can modify a workflow file running on a self-hosted machine
@@ -34,7 +34,7 @@ A way out for rare cases where scoping is a problem.
`##[remove-matcher]owner`
For the this to be usable, the `owner` needs to be discoverable. Therefore, debug print the owner on registration.
For this to be usable, the `owner` needs to be discoverable. Therefore, debug print the owner on registration.
### Single line matcher
@@ -184,7 +184,7 @@ Solving this problem means:
- Use the `github.workspace` (where the repo is cloned on disk)
- Match against a repository to determine the relative path within the repo
This is a place where we diverge from VSCode. VSCode task configuration are specific to the local workspace (workspace root is known or can be specified). We're solving a more generic problem, so we need more information - specifically the `fromPath` property - in order to accurately root the path.
This is a place where we diverge from VSCode. VSCode task configurations are specific to the local workspace (workspace root is known or can be specified). We're solving a more generic problem, so we need more information - specifically the `fromPath` property - in order to accurately root the path.
In order to avoid creating inaccurate hyperlinks on the error issues, the agent will verify the file exists and is in the main repository. Otherwise omit the file property from the error issue and debug trace what happened.
@@ -203,7 +203,7 @@ Problem matchers are unable to interpret severity strings other than `warning` a
However some tools indicate error/warning in different ways. For example `flake8` uses codes like `E100`, `W200`, and `F300` (error, warning, fatal, respectively).
Therefore, allow a property `severity`, sibling to `owner`, which identifies the default severity for the problem matcher. This allows two problem matchers are registered - one for warnings and one for errors.
Therefore, allow a property `severity`, sibling to `owner`, which identifies the default severity for the problem matcher. This allows two problem matchers to be registered - one for warnings and one for errors.
