* fix: add `git` and `curl` to default packages installed
Hi 👋🏼
These packages are used in a ton of actions on the marketplace. It would be nice if they were installed and ready for use instead of having to install them with `apt-get` on every single Github workflow.
* Update Dockerfile
* Update images/Dockerfile
Co-authored-by: Guillermo Caracuel <633810+gcaracuel@users.noreply.github.com>
* Update images/Dockerfile
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
---------
Co-authored-by: Guillermo Caracuel <633810+gcaracuel@users.noreply.github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Upgrade node20: 20.8.1 → 20.13.1
* Call out the release process for `alpine_nodejs` in a comment
* move the comment to the end of the line so it's more obvious which variable it's talking about
* backoff if we retried polling for more than 50 times in less than 30minutes
* run dotnet format
* move delay to after no message trace
* run dotnet format
* Add new SessionConflict return code
* formatting
* Change return type of CreateSessionAsync to new enum
* Update entry scripts to handle new exit code
* Move enum
* consume pipelines service url if present
updates how the `ACTIONS_RUNTIME_URL` variable is set to utilize a new value, `PipelinesServiceUrl` if present in the endpoint. if this value is not present then the existing system connection endpoint is used to retain backward compatibility.
* consume pipelines url
updates how the `ACTIONS_RUNTIME_URL` variable is set to utilize a new value, `PipelinesServiceUrl` if present in the endpoint. if this value is not present then the existing system connection endpoint is used to retain backward compatibility.
While there's an existing retry mechanism for the `docker pull` command
[^1], it's missing for `docker login`.
Similar to the `docker pull` scenario, the container registry could
potentially be briefly unavailable or inaccessible, leading to failed
`docker login` attempt and subsequent workflow run failures.
Since it's container based workflow, there is not way to retry on
customer side. The runner should retry itself.
It also aligns with community feedback [^2].
[^1]: 8e0cd36cd8/src/Runner.Worker/ContainerOperationProvider.cs (L201)
[^2]: https://github.com/orgs/community/discussions/73069
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
This is required in order to ssh into a codespace for the repo:
> error getting ssh server details: failed to start SSH server:
Please check if an SSH server is installed in the container.
If the docker image being used for the codespace does not have an SSH server,
install it in your Dockerfile or, for codespaces that use Debian-based images,
you can add the following to your devcontainer.json:
>
> "features": {
> "ghcr.io/devcontainers/features/sshd:1": {
> "version": "latest"
> }
> }
* add content-type to block blob upload
* Add content-type for sdk path
* fix spacing
* merge headers and only when file extension is .txt
* add conditions
* tweak conditions and path matching
* pass in headers
* add content-type for appendblob
* Set an explicit timeout on ResultsHttpClient
* Hook up retry and standard message handler to ResultsHttpClient
* Remove explicit timeout constructor
* Fix linter
* Bump directly dotnet vulnerable packages
* Use just single file sdk upgrade for vulnerable dependencies
* Save with UTF8-BOM
* Trim down sdk to only Sdk.csproj upgrade
---------
Co-authored-by: Ferenc Hammerl <fhammerl@github.com>
* Add in workflow to automatically generate dotnet SDK patches
* Update workflow to move the creation of the PR until all the hashes have been compiled and added to the path
* Update upgrade to run not in parallel to prevent git command overlaps
* Update for tings feedback and do better user error handling
* JSON spec doesn't have comments
* Has to use the outputs to proxy variables between the runs
* Wrong output variable
* Be more explicit on the branch check
* Fix comments and json output
* Missed variable name in rename
* Fix race condition on jq write
* Update for comments and more optimized hash updates
* Need to forcibly exit for state to be detected
* Fixed the failure to use a variable instead
* hash files translation works with host context translated
* Change file encoding to utf8 for PipelineTemplateConstants.cs
* infer the feature flag on hash files based on the existence of the context
* encoded utf8 with bom
* rename host-workspace to host-work-directory and feature flag the new context var
* Added comment to explain ignore host work directory resolution
Co-authored-by: fhammerl <fhammerl@github.com>
* trigger pipeline
* Move to the github host-workspace context instead of the runner host-work-directory
* remove unused imports
---------
Co-authored-by: fhammerl <fhammerl@github.com>
* Add 'http://' to http(s)_proxy if there is no protocol
Before this commit, these URIs used to be ignored (nullproxy).
The new behaviour aligns with go style http(s)_proxy
* Update src/Runner.Sdk/RunnerWebProxy.cs
Co-authored-by: Nikola Jokic <jokicnikola07@gmail.com>
* Assert that original protocol is preserved
* Use startsWith for testing protocol
* Only modify proxy if useful
---------
Co-authored-by: Nikola Jokic <jokicnikola07@gmail.com>
* Fix `uses: docker://image:tag` steps when container hook is used
* Update src/Runner.Worker/ActionManager.cs
---------
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Set runner environment in runner context and env
Extract runner_environment from the global context and expose in the
`github.runner` context and env as `RUNNER_ENVIRONMENT`.
Signed-off-by: Philip Harrison <philip@mailharrison.com>
* encoding.
---------
Signed-off-by: Philip Harrison <philip@mailharrison.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* [1742] Ensure multiple composite annoations are correctly written.
This implementation uses a collector pattern to allow embedded ExecutionContexts to stash Issue objects for later processing by a non-embedded ancestor ExecutionContext.
Also:
- Provide explicit constructor implementations for ExecutionContext
- Leverage explicit constructors to solidify immutability of several ExecutionContext class members.
- Fixed erroneous call to ExecutionContext.Complete in CompositeActionHandler.cs
- Use a consistent timestamp for FinishTime in ExecutionContext::Complete
* Ensure collected issues are processed only by a non-embedded ExecutionContext.
This was already implicit. Now, just making it explicit.
* Provide a clear mechanism that allows callers to opt-in/opt-out of ExecutionContext::AddIssue's logging behavior.
* Addressed deserialization inconsistencies in TimelineRecord.cs
* Added TimelineRecord unit tests.
* Refined unit tests related to TimelineRecord::Variables case-insensitivity
* Add a unit test that verifies ExecutionContextLogOptions::LogMessageOverride has the desired effect.
* Responded to PR feedback.
* Don't allow embedded ExecutionContexts to add Issues to a TimelineRecord
* Only upload to Results with new job message type
* No need to have separate websocketFeedServer
* Linting fix
* Update src/Runner.Common/JobServerQueue.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* add connection timeout
* Consolidate initializing webclient to result client
* Retry websocket delivery for console logs
* Linter fix
* Do not give up for good, reconnect again in 10 minutes
* Has to reset delivered
* Only first time retry 3 times to connect to websocket
---------
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Rename AcquireJobRequest::StreamID to AcquireJobRequest::JobMessageID to match corresponding server-side update.
* appeased the linter
* Added unit tests to prove AcquireJobRequest serialization/deserialization is as-expected.
* Distinguish unit test variations.
* Incorporated PR Feedback.
* which handles broken symlink & unit test added (#2150)
* Update src/Runner.Sdk/Util/WhichUtil.cs
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* fix pr comments
* trace log added, in case we find a symlink that is broken
* add check in case the target of the symlink is a relative path; added test that check symlink that targets a full path; added test that check symlink that targets a relative path;
* fix tests
* fix tests for linux
---------
Co-authored-by: Eli Entelis <eli.entelis@hexagon.com>
Co-authored-by: Eli Entelis <42981948+Eliminator1999@users.noreply.github.com>
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Also send Steps update to Results service
* Refactor to separate results server from current job server
* If hit any error while uploading to Results, skip Results upload
* Add proxy authentication and buffer request for WinHttpHandler
* Remove unnecessary null guard
* Also send Results telemetry when step update fails
* IResultsServer is not disposable
* Guard against NullReference while creating HostContext
* Throw on IOUtil loading object if content is empty or object is null
* removed unused dependency
* Changed exceptions to ArgumentNullException and ArgumentException
* fixed my mistake on LoadObject
* fixed tests
* trigger workflows
* trigger workflows
* encode files using utf8
* terminate the runner on deprication message
* added TaskAgentVersion exception to catch deprication
* AccessDenied exception with inner exception InvalidTaskAgent
* Access denied exception in program and in message listener
* Fixed copy
* remove trace message from message listener
* Bypass top level domain even if no_proxy specified it with leading '.'
E.g. no_proxy='.github.com' will now bypass github.com.
* Bypass proxy on all hosts when no_proxy is * (wildcard)
* Undo '.' stripping
* Simplify unit tests
* Respect wildcard even if it's one of many no_proxy items
* Runner service exit after consecutive re-try exits
* Rename failure counts and include reset count on runner listening for jobs
* Changed from graceful shutdown to stopping=true
* Revert "Revert "Uploading step logs to Results as well (#2422)" (#2437)"
This reverts commit 8c096baf49.
* Properly guard the upload to results feature
* Delete skipped file if deletesource is true
* Update lint.yml
Don't ignore the formatting errors
* Add formatting made by @cory-miller
* Use dotnet format
* Format only modified files
* Add instruction to contribute.md
* Use git status instead of git diff
* Rename queue to results queue
* Add results contracts
* Add Results logging handling
* Adding calls to create and finalize append blob
* Modifications for azurite upload
* Only call upload complete on final section and remove size
* Make method specific to step log so we can support job log later
* Change contract for results
* Add totalline count to the result log upload file
* Actually pass lineCount to Results Service
* Fix typos
* Code cleanup
* Fixing typos
* Apply suggestions from code review
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
---------
Co-authored-by: Brittany Ellich <brittanyellich@github.com>
Co-authored-by: Konrad Pabjan <konradpabjan@github.com>
* Sanitize OS Desc for UserAgents
* Only drop brackets if needed, refactoring
* Add missing ')'
* Readd missing brackets around '(header)'
* Add comments
* Use bracket solution from SDK
* Rename tests
* send more stuff as part of job completed
* feedback
* set only once
* feedback
* feedback
* fix test
* feedback
* nit: spacing
* nit: line
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
---------
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Defer evaluation of a step's DisplayName until its condition is evaluated.
* Formalize TryUpdateDisplayName and EvaluateDisplayName as members of interface `IStep` (#2374)
* Remove unnecessary timelineId and timelineRecordId and use Guid stepId
* Log upload error to kusto
* Remove try-catch
* Using a well known telmetry record to avoid replacing issues
* fix Guid format
* Use results service for uploading step summaries
* Use results summary over generic results naming convention
* Apply suggestions from code review
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Addressing feedback
* Fix merge issue
* Remove empty line
* Update Results json objects to use snake case
* Adding the reference
Co-authored-by: Yang Cao <yacaovsnc@github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Added env variable to control wether the terminal is silent
* Log to stdout if PrintLogToStdout is enabled
* Extracted console logging to stdouttracelistener
* Remove useless usings
* Rewrite TraceListener as superclass
* Only print to stdout if env is set
* Add comment for Console.Out
* Format Listener
* Revert var name in terminal
* Check env in hostcontext instead of Tracing constructor
* Remove superclass & dupe logging code
* Log hostType
* Readonly '_' prefix 'hostType'
* Fix test
* Revert Terminal change
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Workflow
* add back github-token to id:image
* added handle to image name
* removed core require
* multi line added :latest
* added label
* added repository_owner in IMAGE_NAME
* with the release
* release
* markdown label description
* Remove markdown desciprion
* Remove double quotes in labels
* Reverted back releaseVersion
* run.sh installs SIGINT and SIGTERM traps to gracefully stop runner
* replaced trap to force wait for child processes and to send kill to run-helper instead of Runner.Listener
* run with signal handling if RUNNER_MANUALLY_TRAP_SIG is set
* Update src/Misc/layoutroot/run.sh
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Allow container.image to be null/empty
* Remove unnecessary workflow type
* Update src/Sdk/DTPipelines/Pipelines/ObjectTemplating/PipelineTemplateConverter.cs
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Rename ConvertToJobContainer to ConvertToContainer
It converts serviceContainers too
* Remove unused parameter
AllowExpressions was always false
* Allow service in yaml with empty string for value
* Don't attempt to start services without an image
* Improve error messages
* Revert "Remove unused parameter"
This reverts commit f4ab2d50d0.
* Revert "Rename ConvertToJobContainer to ConvertToContainer"
This reverts commit ffc62f8343.
* Fix revert merge conflict
* Removed info logs
* Added info log for services without container images
Co-authored-by: moonblade <moonblade168@gmail.com>
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
Co-authored-by: Ava Stancu <avastancu@github.com>
For runners that are already configured but need to add systemd services after the fact, a new command option is added to generate the file only. Once generated, ./svc.sh install and other commands will be available.
This also adds support for falling back to the tenant name in the Actions URL in cases when the GitHub URL is not provided, such as for our hosted larger runners.
* Avastancu/joannaakl/service container error log (#2110)
* adding support for a service container docker logs
* Adding Unit test to ContainerOperationProvider
* Adding another test to ContainerOperationProvider
* placed the docker logs output in dedicated ##group section
* Removed the exception thrown if the service container was not healthy
* Removed duplicated logging to the executionContext
* Updated the container logs sub-section message
* Print service containers only if they were healthy
Unhealthy service logs are printed in ContainerHealthCheckLogs called prior to this step.
* Removed recently added method to inspect docker logs
The method was doing the same thing as the existing DockerLogs method.
* Added execution context error
This will make a failed health check more visible in the UI without disrupting the execution of the program.
* Removing the section 'Waiting for all services to be ready'
Since nested subsections are not being displayed properly and we already need one subsection per service error.
* Update src/Runner.Worker/Container/DockerCommandManager.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/TestHostContext.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Change the logic for printing Service Containers logs
Service container logs will be printed in the 'Start containers' section only if there is an error.
Healthy services will have their logs printed in the 'Stop Containers' section.
* Removed unused import
* Added back section group.
* Moved service containers error logs to separate group sections
* Removed the test testing the old logic flow.
* Remove unnecessary 'IsAnyUnhealthy' flag
* Remove printHello() function
* Add newline to TestHostContext
* Remove unnecessary field 'UnhealthyContainers'
* Rename boolean flag indicating service container failure
* Refactor healthcheck logic to separate method to enable unit testing.
* Remove the default value for bool variable
* Update src/Runner.Worker/ContainerOperationProvider.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Runner.Worker/ContainerOperationProvider.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Rename Healthcheck back to ContainerHealthcheck
* Make test sequential
* Unextract the container error logs method
* remove test asserting thrown exception
* Add configure await
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Add back test asserting exception
* Check service exit code if there is no healtcheck configured
* Remove unnecessary healthcheck for healthy service container
* Revert "Check service exit code if there is no healtcheck configured"
This reverts commit fec24e8341.
Co-authored-by: Ava S <avastancu@github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Do not fail service containers without the healthcheck
Co-authored-by: JoannaaKL <joannaakl@github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* adding support for a service container docker logs
* Adding Unit test to ContainerOperationProvider
* Adding another test to ContainerOperationProvider
* placed the docker logs output in dedicated ##group section
* Removed the exception thrown if the service container was not healthy
* Removed duplicated logging to the executionContext
* Updated the container logs sub-section message
* Print service containers only if they were healthy
Unhealthy service logs are printed in ContainerHealthCheckLogs called prior to this step.
* Removed recently added method to inspect docker logs
The method was doing the same thing as the existing DockerLogs method.
* Added execution context error
This will make a failed health check more visible in the UI without disrupting the execution of the program.
* Removing the section 'Waiting for all services to be ready'
Since nested subsections are not being displayed properly and we already need one subsection per service error.
* Update src/Runner.Worker/Container/DockerCommandManager.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/TestHostContext.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Change the logic for printing Service Containers logs
Service container logs will be printed in the 'Start containers' section only if there is an error.
Healthy services will have their logs printed in the 'Stop Containers' section.
* Removed unused import
* Added back section group.
* Moved service containers error logs to separate group sections
* Removed the test testing the old logic flow.
* Remove unnecessary 'IsAnyUnhealthy' flag
* Remove printHello() function
* Add newline to TestHostContext
* Remove unnecessary field 'UnhealthyContainers'
* Rename boolean flag indicating service container failure
* Refactor healthcheck logic to separate method to enable unit testing.
* Remove the default value for bool variable
* Update src/Runner.Worker/ContainerOperationProvider.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Runner.Worker/ContainerOperationProvider.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Rename Healthcheck back to ContainerHealthcheck
* Make test sequential
* Unextract the container error logs method
* remove test asserting thrown exception
* Add configure await
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Test/L0/Worker/ContainerOperationProviderL0.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Add back test asserting exception
* Check service exit code if there is no healtcheck configured
* Remove unnecessary healthcheck for healthy service container
* Revert "Check service exit code if there is no healtcheck configured"
This reverts commit fec24e8341.
Co-authored-by: Ava S <avastancu@github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Adding a new vars context for non-secret variables
* Fix test case
* Trigger checks
* Remove variables from env context and environment varibale
* remove extra references
* Add prefix handling to configuration variables
* Fix test cases
* Consume variables using vars in context data
* removed action_yaml changes
* update.sh new logic with creating a file and waiting for it for 30 sec
* pr refactor
* removing file when it's detected bu run-helper
* Update src/Misc/layoutroot/run-helper.sh.template
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* clean up update.finished in Runner.Listener right before it starts a process _update.sh
* pr fix IOUtil.DeleteFile
* self update widnows version - cmd
* same logic for returnCode 4 - ephemeral
* Init var so cmd doesn't run into syntax errors
* Use constants, setting a var messed up ERRORLEVEL
* Use var for updatefile
Co-authored-by: stefanruvceski <ruvceskistefan@github.com>
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
Co-authored-by: Ferenc Hammerl <hammerl.ferenc@gmail.com>
* Created env var for forcing node12 actions to run on node16
* get value of hostContext environment variable
* changing location of forced node version check
* small code refactoring
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* more of small code refactoring
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* refactoring of conditions for getting internal node version
* changing expected value for node version env var
* Adding empty line between two methods
* Created method GetNodeVersion
* GetNodeVersion from function to inline call and PR fixes
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
* Jsut simple solution without additional funcs
* Delete old comment
* resolve
* Refactor retry function, make it more common
* Make retry function generic, get rid of extra params
* delete extra using
* Add cancellation token and limit of attempts
* Add some additional logging
* Rework condition
* replace to do..while
* return `while (true)` to simplify code structure
* Add other cancelling token, add TODO comment
* Added ability to run Dockerfile.SUFFIX ContainerAction
* Extracted IsDockerFile method
* reformatted, moved from index to Last()
* extracted IsDockerfile to DockerUtil with L0
* added check for IsDockerfile to account for docker://
* updated test to clearly show path/dockerfile:tag
* fail if Data.Image is not Dockerfile or docker://[image]
* Setup noops for JobPrepare and JobCleanup hooks
* Add container jobstarted and jobcomplete hooks
* Run 'index.js' instead of specific command hooks
* Call jobprepare with command arg
* Use right command name (hardcoded)
Co-authored-by: Nikola Jokic <nikola-jokic@users.noreply.github.com>
* Invoke hooks with arguments
* Add PrepareJob hook to work with jobcontainers
Co-authored-by: Nikola Jokic <nikola-jokic@users.noreply.github.com>
* Rename methods
* Use new hookcontainer to run prep and clean hooks
* Get path from ENV
* Use enums
* Use IOUtils.cs
* Move container files to folder
* Move namespaces
* Store "state" between hooks
* Remove stdin stream in containerstephosts
* Update Constants.cs
* Throw if stdin fails
* Cleanup obvious nullrefs and unused vars
* Cleanup containerhook directory
* Call step exec hook
* Fix windows build
* Remove hook from hookContainer
* Rename file
* More renamings
* Add TODOs
* Fix env name
* Fix missing imports
* Fix imports
* Run script step on jobcontainer
* Enable feature if env is set
* Update ContainerHookManager.cs
* Update ContainerHookManager.cs
* Hooks allowed to work even when context isn't returned
* Custom hooks enabled flag and additional null checks
* New line at the end of the FeatureFlagManager.cs
* Code refactoring
* Supported just in time container building or pulling
* Try mock-build for osx
* Build all platforms
* Run mock on self-hosted
* Remove GITHUB prefix
* Use ContainerHooksPath instead of CustomHooksPath
* Null checks simplified
* Code refactoring
* Changing condition for image builing/pulling
* Code refactoring
* TODO comment removed
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Call container step if FF is on
* Rename run script function
* Use JToken instead of dynamic
* Add TODO
* Small refactoring + renames + TODOs
* Throw on DetermineNodeRuntimeVersion
* Fix formatting
* Add run-container-step
* Supported nodeJS in Alpine containers
* Renamed Alpine to IsAlpine in HookResponse
* Method for checking platform for alpine container
* Added container hooks feature flag check
* Update IsHookFeatureEnabled with new params
* Rename featureflag method
* Finish rename
* Set collection null values to empty arrays when JSON serialising them
* Disable FF until we merge
* Update src/Runner.Worker/Container/ContainerHooks/HookContainer.cs
* Fix method name
* Change hookargs to superclass from interface
* Using only Path.Combine in GenerateResponsePath
* fix merge error
* EntryPointArgs changed to list of args instead of one args string
* Changed List to IEnumerable for EntryPointArgs and MountVolumes
* Get ContainerRuntimePath for JobContainers from hooks
* Read ContainerEnv from response file
* Port mappings saved after creating services
* Support case when responseFile doesn't exist
* Check if response file exists
* Logging in ExecuteHookScript
* Save hook state after all 4 hooks
* Code refactoring
* Remove TODO
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Remove second TODO
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Removing container env changes
* Removing containerEnv and dockerManager
* Delete mock-build.yml
* Update IOUtil.cs
* Add comment about containerhooks
* Fix merge mistake
* Remove solved todo
* Determine which shell to use for hooks scenario
* Overload for method ExecuteHookScript with prependPath as arg
* Adding HostContext to the GetDefaultShellForScript call
* prependPath as a mandatory parameter
* Improve logging for hooks
* Small changes in logging
* Allow null for ContainerEntryPointArgs
* Changed log messages
* Skip setting EntryPoint and EntryPointArgs if hooks are enabled
* Throw if IsAlpine is null in PrepareJob
* Code refactoring - added GetAndValidateResponse method
* Code refactoring
* Changes in exception message
* Only save hookState if returned
* Use FF from server
* Empty line
* Code refactoring
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Send null instead of string empty
* Remove TODO
* Code refactoring and some small changes
* Allow Globals to be null to pass L0
* Fix setup in StepHostL0
* Throw exception earlier if response file doesn't exist and prepare_job hook is running
* Refactoring GetResponse method
* Changing exception message if response file is not found
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Chaning exception message if isAlpine is null for prepare_job hook
* Rename hook folder
* Fail if compatible hookfile not found
* Use .Value instead of casting bool? to bool
* Format spacing
* Formatting
* User user and system mvs
* Use variables instead of entire context in featuremanager
* Update stepTelemetry if step uses containerhooks
* Restore import
* Remove unneccessary field from HookContainer
* Refactor response context and portmappings
* Force allow hooks if FF is on
* Code refactoring
* Revert deleting usings
* Better hookContainer defaults and use correct portmapping list
* Make GetDefaultShellForScript a HostContext extension method
* Generic hookresponse
* Code refactoring, unnecessary properties removed - HookContainer moved to the HookInput.cs
* Remove empty line
* Code refactoring and better exception handling
* code refactor, removing unnecessary props
* Move hookstate to global ContainerHookState
* Trace exception before we throw it for not losing information
* Fix for null ref exception in GetResponse
* Adding additional check for null response in prepareJob hook
* Refactoring GetResponse with additional check
* Update error messages
* Ports in ResponseContainer changed from IList to IDictionary
* Fix port format
* Include dockerfile
* Send null Registry obj if there's nothing in it
* Minor formatting
* Check if hookIndexPath exists relocated to the ContainerHookManager
* Code refactoring - ValidateHookExecutable added to the ContainerHookManager
* check if ContainerHooksPath when AllowRunnerContainerHooks is on
* Submit JSON telemetry instead of boolean
* Prefix step hooks with "run"
* Rename FeatureManager
* Fix flipped condition
* Unify js shell path getter with ps1 and sh getter
* Validate on run, not on instantiation of manager
* Cleanup ExecuteAsync methods
* Handle exception in executeHookScript
* Better exception types
* Remove comment
* Simplify boolean
* Allow jobs without jobContainer to run
* Use JObject instead of JToken
* Use correct Response type
* Format class to move cleanupJobAsync to the end of public methods
* Rename HookIndexPath to HookScriptPath
* Refactor methods into expression bodies
* Fix args class hierarchy
* Fix argument order
* Formatting
* Fix nullref and don't swallow stacktrace
* Whilelist HookArgs
* Use FF in FeatureManager
* Update src/Runner.Worker/ContainerOperationProvider.cs
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
* Update src/Runner.Worker/ActionRunner.cs
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
* Update src/Runner.Worker/ActionRunner.cs
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
* Only mount well known dirs to job containers
* Get trace from hostcontext
* Use hook execution for setting telemetry
Co-authored-by: Nikola Jokic <nikola.jokic@akvelon.com>
Co-authored-by: Nikola Jokic <nikola-jokic@users.noreply.github.com>
Co-authored-by: Nikola Jokic <97525037+nikola-jokic@users.noreply.github.com>
Co-authored-by: Stefan Ruvceski <stefan.ruvceski@akvelon.com>
Co-authored-by: ruvceskistefan <96768603+ruvceskistefan@users.noreply.github.com>
Co-authored-by: Thomas Boop <thboop@github.com>
Co-authored-by: stefanruvceski <ruvceskistefan@github.com>
Co-authored-by: Tingluo Huang <tingluohuang@github.com>
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
It generated invalid arguments for `Process()` when the `bash` command itself was an argument as well, for example:
```
_proc.StartInfo.FileName = "/usr/bin/docker";
_proc.StartInfo.Arguments = "exec -i --workdir /__w/container-hook-e2e/container-hook-e2e 47105c66144d8809d9fa2bce9a58ea0564cd14def0ae7952cd6231fba3576db1 sh -e '/__w/_temp/fd086560-cb92-4f3b-a99c-35a6b7b1bbdb.sh'";
```
* Job hook provider now sets shell name for script handler
* fixed script handler and job hook provider to work with the name without fail
* returned used import by osx
* fixed order of imports
* added quotes around resolved script path allowing space in script path
* added quotes around bash and sh _defaultArguments
* Changed double quotes to single quotes in sh -e
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Changed double quotes to single quotes in bash
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Added ability to run Dockerfile.SUFFIX ContainerAction
* Extracted IsDockerFile method
* reformatted, moved from index to Last()
* extracted IsDockerfile to DockerUtil with L0
* added check for IsDockerfile to account for docker://
* updated test to clearly show path/dockerfile:tag
* fail if Data.Image is not Dockerfile or docker://[image]
* Added warning in case of invalid combination of command and flags and/or arguments
* Deleting unnecessary comments
* Added separate list for generic options
* Added PAT to the valid remove options
* Added command name to the error message
* composite action github.action_path set based on the StepHost
* in progress on updating github context for input template
* Fixed updating the context data for evaluation
* refactored logic so it is a little cleaner
* removed resolving the action_path in CompositeActionHandler
* removed added DeepClone
* added feature flag and modified the dict in place
* refactored step host to change context data. Added L0
* repaired spaces
* moved logic from step host to execution context, added recursive translation
* removed empty lines
* moved to extension methods
* Update src/Test/L0/Worker/StepHostL0.cs
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Added continue on error to composite action
* changed from boolean-strategy-context -> boolean-steps-context for action_yaml
* refactored composite handler to always set outcome
* retrigger checks
* fixed typo in ??= operator
* boolean-steps-context accepts the same context as string-steps-context
* setting the outcome only on continue-on-error
* moved continue on error logic to the execution context
* Added L0 table tests for continue-on-error ExecutionContext
* Added missing mocks on StepsRunnerL0 for this update
* removed empty line and added one line separating the call
* Removed empty line
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Fixing null reference exception when configuring runner with invalid repo URL or token
* Throw exception instead of ConvertFromJson
* Storing the response code
* Add annotations if node 12 action is found
* Better placeholder
* Only warn if FF is on
* Move annotation logic
* Pass in the LTS Url
* Raise annotation right before executing the action
* Match server side FF name
* Change name back to features
* Better warning text
* Update src/Runner.Common/Constants.cs
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
Co-authored-by: Thomas Boop <52323235+thboop@users.noreply.github.com>
* feed via websocket
* feed via websocket
* feedback
* ensure right schema is used
* fix resiliency
* some fixes
* fix sending message
* chunk data
* let's abort, which will also dispose
* close gracefully
* use safe_sleep executable in bash scripts
* new line at the end of safe_sleep bash script
* Replacing relative paths with absolute paths and changing location of safe_sleep
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Set GH actions Node version to 16 if FF is on unless user opted out
* Add L0s (WIP)
* Wrap tests into theory
* Only check for node12 actions
* Refactor node version picking
* Lets allow up to 150 characters on linux/mac, just to avoid some issues with runner naming
* Add 4 randomized digits on mac/linux
* fix pragma issue
* fix test
* Address pr feedback
* reduce complexity
* lets make it cleaner!
* fix test
* fix logic
* Issue 1596: runner throws nullref exception when writting env var
* Adding tests for missing new line after EOF marker
* Changing newline to new line
* Issue 1662: Adding retry policy for methods GetTenantCredential and GetJITRunnerTokenAsync
* Adding HttpClient creation to the retry
* Random backoff time
* Use 16 to run RunnerService.js
* Execute hashfiles using node16
* Run downloadCert.js using node16
* Run makeWebRequest.js using node16
* Run macos-run-invoker.js using node16
* Run hashFiles.js using node16
* Update tests to use node16
* Update documentation to recommend node16
* Duplicate macos service js fix for 16
* Add PR link
* Revert ADR node change
* Merge node12/16 retainment IFs
* Try both node12 and node16
* Close if
* Revert "Update tests to use node16"
This reverts commit bbca7b9f1c.
* Fix condition
* Unfurl if condition
* Allow user to force a node version
* Format update template
* Comment env var
* Rename vars
* Fix naming
* Fix rename
* Set node ver override if job message has it
* Format executionContext
* Can only receive 'forceNode12' or nothing from FF
No specific node version from server
Co-authored-by: Ferenc Hammerl <hammerl.ferenc@gmail.com>
* Solving issue with debugging on macOS M1
* Fixing problem with debugging on macOS M1
* Adding targetArchitecture in launch.json configs
* Code refactor
* Kill node process to recover handle
So we can print to the console in Runner.Listener once again
* Revert testing changes
Co-authored-by: Ferenc Hammerl <hammerl.ferenc@gmail.com>
* First prototype of step summary environment variable
* Fix file contention issue
* Try to simplify cleaning up file references
* use step id as md file name, queue file attachment
* separate logic into attachment summary func
* Fix indentation
* Add (experimental) feature flag support
* reorganize summary upload determination logic
* file i/o exception handling + pr feedback
* Revert changes for now to reintroduce them later
* Add skeleton SetStepSummaryCommand
* Update step summary feature flag name
* Port ShouldUploadAttachment from previous iteration
* Port QueueStepSummaryUpload from previous iteration
* Improve exception handling when uploading attachment
* Add some minor logging improvements
* Refuse to upload files larger than 128k
* Implement secrets scrubbing
* Add TODO comment to remove debugging temp files
* Add first tests
* Add test for secret masking
* Add some naming/style fixes suggested in feedback
* inline check for feature flag
* Inline method for style consistency
* Make sure that scrubbed file doesn't exist before creating it
* Rename SetStepSummaryCommand to CreateStepSummaryCommand
* Fix error handling messages
* Fix file command name when registering extension
* Remove unnecessary file deletion
Co-authored-by: Rob Herley <robherley@github.com>
* Only execute post for actions that have one
* Working container runner update with run.sh
* Revert "Only execute post for actions that have one"
This reverts commit 9675941fdb.
* Relaunch the listener without quitting run.cmd
* Fix typo
* Extract most os run.sh logic so we can update it
* Add bash line endings
* Extract the logic from run.cmd
* Add EoF lines
* Add unexpected ERRORLEVEL messages to cmd
* Simplify contract between run and helper
* Remove unused exit
* WIP: run a copy of the helper so it's safe to update
* Throw NonRetryableException if not configured
* Log and format
* Fix typo
* Fix typo
* Use helper template system for bash as well
* Update run.sh
* Remove unnecessary comments
* Use ping instead of timeout
* Use localhost in ping-timeout (n times, w timeout)
Co-authored-by: Ferenc Hammerl <hammerl.ferenc@gmail.com>
* Revert "Make `run.sh|cmd` handle update without quitting so containers using them as entrypoints don't exit on update (#1494)"
d8251bf912
* update runnerversion as well
* Update 0276-problem-matchers.md
Update to reflect current behavior
* Update docs/adrs/0276-problem-matchers.md
Co-authored-by: Ferenc Hammerl <31069338+fhammerl@users.noreply.github.com>
* Only execute post for actions that have one
* Working container runner update with run.sh
* Revert "Only execute post for actions that have one"
This reverts commit 9675941fdb.
* Relaunch the listener without quitting run.cmd
* Fix typo
* Extract most os run.sh logic so we can update it
* Add bash line endings
* Extract the logic from run.cmd
* Add EoF lines
* Add unexpected ERRORLEVEL messages to cmd
* Simplify contract between run and helper
* Remove unused exit
* WIP: run a copy of the helper so it's safe to update
* Throw NonRetryableException if not configured
* Log and format
* Fix typo
* Fix typo
* Use helper template system for bash as well
* Update run.sh
* Remove unnecessary comments
* Use ping instead of timeout
* Use localhost in ping-timeout (n times, w timeout)
Co-authored-by: Ferenc Hammerl <hammerl.ferenc@gmail.com>
Many people open bug reports or feature requests in the `actions/runner`
repository that are more generally about GitHub Actions. Often changes
in GitHub Actions are cross-cutting across multiple teams or feature
areas, so it's best if we direct people to the more general areas
(Actions Community Support or GitHub Feedback) so that we can get the
most eyes on the problem and give the quickest response.
* conditional support for composite actions
* Fix Conditional function evaluation
* Push launch.json temporarily
* Revert "Push launch.json temporarily"
* rename context
* Cleanup comments
* fix success/failure functions to run based on pre/main steps
* idea of step_status
* change to use steps context, WIP
* add inputs to possible if condition expressions
* use action_status
* pr cleanup
* Added right stages
* Test on stage in conditional functions
* Fix naming and formatting
* Fix tests
* Add success and failure L0s
* Remove comment
* Remove whitespace
* Undo formatting
* Add L0 for step-if parsing
* Add ADR
Co-authored-by: Thomas Boop <thboop@github.com>
* Always register post steps for local actions
* Register post steps along with their conditions
* remove debug code
Co-authored-by: Ferenc Hammerl <fhammerl@github.com>
about: If you have issues with GitHub Actions, please follow the "support for GitHub Actions" link, below.
title: ''
labels: bug
assignees: ''
---
<!--
👋 You're opening a bug report against the GitHub Actions**runner application**.
🛑 Please stop if you're not certain that the bug you're seeing is in the runner application - if you have general problems with actions, workflows, or runners, please see the [GitHub Community Support Forum](https://github.community/c/code-to-cloud/52) which is actively monitored. Using the forum ensures that we route your problem to the correct team. 😃
-->
**Describe the bug**
A clear and concise description of what the bug is.
about:If you have feedback or suggestions about GitHub Actions, please open a discussion (or add to an existing one) in the GitHub Actions Feedback. GitHub Actions Product Managers and Engineers monitor the feedback forum.
Thank you 🙇♀ for wanting to create a feature in this repository. Before you do, please ensure you are filing the issue in the right place. Issues should only be opened on if the issue **relates to code in this repository**.
* If you have found a security issue [please submit it here](https://hackerone.com/github)
* If you have questions or issues with the service, writing workflows or actions, then please [visit the GitHub Community Forum's Actions Board](https://github.community/t5/GitHub-Actions/bd-p/actions)
* If you are having an issue or question about GitHub Actions then please [contact customer support](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-github-actions#contacting-support)
If you have a feature request that is relevant to this repository, the runner, then please include the information below:
**Describe the enhancement**
A clear and concise description of what the features or enhancement you need.
**Code Snippet**
If applicable, add a code snippet.
**Additional information**
Add any other context about the feature here.
NOTE: if the feature request has been agreed upon then the assignee will create an ADR. See docs/adrs/README.md
close-issue-message:"This issue does not seem to be a problem with the runner application, it concerns the GitHub actions platform more generally. Could you please post your feedback on the [GitHub Community Support Forum](https://github.com/orgs/community/discussions/categories/actions) which is actively monitored. Using the forum ensures that we route your problem to the correct team. 😃"
close-issue-message:"Thank you for your interest in the runner application and taking the time to provide your valuable feedback. We kindly ask you to redirect this feedback to the [GitHub Community Support Forum](https://github.com/orgs/community/discussions/categories/actions-and-packages) which our team actively monitors and would be a better place to start a discussion for new feature requests in GitHub Actions. For more information on this policy please [read our contribution guidelines](https://github.com/actions/runner#contribute). 😃"
run:echo "::error links::feature/dotnet-sdk-upgrade${{ steps.fetch_latest_version.outputs.DOTNET_LATEST_MAJOR_MINOR_PATCH_VERSION }} https://github.com/actions/runner/tree/feature/dotnet-sdk-upgrade${{ steps.fetch_latest_version.outputs.DOTNET_LATEST_MAJOR_MINOR_PATCH_VERSION }}::Branch feature/dotnetsdk-upgrade/${{ steps.fetch_latest_version.outputs.DOTNET_LATEST_MAJOR_MINOR_PATCH_VERSION }} already exists. Please take a look and delete that branch if you wish to recreate"
- name:Create a warning annotation if no need to update
run:echo "::warning ::Latest DotNet SDK patch is ${{ steps.fetch_latest_version.outputs.DOTNET_LATEST_MAJOR_MINOR_PATCH_VERSION }}, and we are on ${{ steps.fetch_latest_version.outputs.DOTNET_CURRENT_MAJOR_MINOR_PATCH_VERSION }}. No need to update"
stale-issue-message:"This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 15 days."
close-issue-message:"This issue was closed because it has been stalled for 15 days with no activity."
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.
@@ -23,4 +22,4 @@ Runner releases:
## Contribute
We accept contributions in the form of issues and pull requests. [Read more here](docs/contribute.md) before contributing.
We accept contributions in the form of issues and pull requests. The runner typically requires changes across the entire system and we aim for issues in the runner to be entirely self contained and fixable here. Therefore, we will primarily handle bug issues opened in this repo and we kindly request you to create all feature and enhancement requests on the [GitHub Feedback](https://github.com/community/community/discussions/categories/actions-and-packages) page. [Read more about our guidelines here](docs/contribute.md) before contributing.
@@ -10,7 +10,7 @@ Compilation failures during a CI build should surface good error messages.
For example, the actual compile errors from the typescript compiler should bubble as issues in the UI. And not simply "tsc exited with exit code 1".
VSCode has an extensible model for solving this type of problem. VSCode allows users to configure which problems matchers to use, when scanning output. For example, a user can apply the `tsc` problem matcher to receive a rich error output experience in VSCode, when compiling their typescript project.
VSCode has an extensible model for solving this type of problem. VSCode allows users to configure which [problems matchers](https://code.visualstudio.com/docs/editor/tasks#_defining-a-problem-matcher) to use, when scanning output. For example, a user can apply the `tsc` problem matcher to receive a rich error output experience in VSCode, when compiling their typescript project.
The problem-matcher concept fits well with "setup" actions. For example, the `setup-nodejs` action will download node.js, add it to the PATH, and register the `tsc` problem matcher. For the duration of the job, the `tsc` problem matcher will be applied against the output.
@@ -18,21 +18,23 @@ The problem-matcher concept fits well with "setup" actions. For example, the `se
@@ -24,7 +24,7 @@ The runner will look for a file `.setup_info` under the runner's root directory,
}
]
```
The runner will use `##[group]` and `##[endgroup]` to fold all detail info into an expandable group.
The runner will use `::group` and `::endgroup` to fold all detail info into an expandable group.
Both [virtual-environments](https://github.com/actions/virtual-environments) and self-hosted runners can use this mechanism to add extra logging info to the `Set up job` step's log.
# ADR 1438: Support Conditionals In Composite Actions
**Date**: 2021-10-13
**Status**: Accepted
## Context
We recently shipped composite actions, which allows you to reuse individual steps inside an action.
However, one of the [most requested features](https://github.com/actions/runner/issues/834) has been a way to support the `if` keyword.
### Goals
- We want to keep consistent with current behavior
- We want to support conditionals via the `if` keyword
- Our built in functions like `success` should be implementable without calling them, for example you can do `job.status == success` rather then `success()` currently.
### How does composite currently work?
Currently, we have limited conditional support in composite actions for `pre` and `post` steps.
These are based on the `job status`, and support keywords like `always()`, `failed()`, `success()` and `cancelled()`.
However, generic or main steps do **not** support conditionals.
By default, in a regular workflow, a step runs on the `success()` condition. Which looks at the **job****status**, sees if it is successful and runs.
By default, in a composite action, main steps run until a single step fails in that composite action, then the composite action is halted early. It does **not** care about the job status.
Pre, and post steps in composite actions use the job status to determine if they should run.
### How do we go forward?
Well, if we think about what composite actions are currently doing when invoking main steps, they are checking if the current composite action is successful.
Lets formalize that concept into a "real" idea.
- We will add an `action_status` field to the github context to mimic the [job's context status](https://docs.github.com/en/actions/learn-github-actions/contexts#job-context).
- We have an existing concept that does this `action_path` which is only set for composite actions on the github context.
- In a composite action during a main step, the `success()` function will check if `action_status == success`, rather then `job_status == success`. Failure will work the same way.
- Pre and post steps in composite actions will not change, they will continue to check the job status.
### Nested Scenario
For nested composite actions, we will follow the existing behavior, you only care about your current composite action, not any parents.
For example, lets imagine a scenario with a simple nested composite action
```
- Job
- Regular Step
- Composite Action
- runs: exit 1
- if: always()
uses: A child composite action
- if: success()
runs: echo "this should print"
- runs: echo "this should also print"
- if: success()
runs: echo "this will not print as the current composite action has failed already"
```
The child composite actions steps should run in this example, the child composite action has not yet failed, so it should run all steps until a step fails. This is consistent with how a composite action currently works in production if the main job fails but a composite action is invoked with `if:always()` or `if: failure()`
### Other options explored
We could add the `current_step_status` to the job context rather then `__status` to the steps context, however this comes with two major downsides:
- We need to support the field for every type of step, because its non trivial to remove a field from the job context once it has been added (its readonly)
- For all actions besides composite it would only every be `success`
- Its weird to have a `current_step` value on the job context
- We also explored a `__status` on the steps context.
- The `__` is required to prevent us from colliding with a step with id: status
- This felt wrong because the naming was not smooth, and did not fit into current conventions.
### Consequences
- github context has a new field for the status of the current composite action.
- We support conditional's in composite actions
- We keep the existing behavior for all users, but allow them to expand that functionality.
This ADR details the design changes for supporting custom configurable hooks for on various runner events. This has been a long requested user feature [here](https://github.com/actions/runner/issues/1543), [here](https://github.com/actions/runner/issues/699) and [here](https://github.com/actions/runner/issues/1116) for users to have more information on runner observability, and for the ability to run cleanup and teardown jobs.
This feature is mainly intended for self hosted runner administrators.
**What we hope to solve with this feature**
1. A runner admininstrator is able to add custom scripts to cleanup their runner environment at the start or end of a job
2. A runner admininstrator is able to add custom scripts to help setup their runner environment at the beginning of a job, for reasons like [caching](https://github.com/actions/runner/issues/1543#issuecomment-1050346279)
3. A runner administrator is able to grab custom telemetry of jobs running on their self hosted runner
**What we don't think this will solve**
- Policy features that require certain steps run at the beginning or end of all jobs
- This would be better solved to in a central place in settings, rather then decentralized on each runner.
- The Proposed `Notification Hooks for Runners` is limited to self hosted runners, we don't beileve Policy features should be
- Reuse scenarios between jobs are covered by [composite actions](https://docs.github.com/en/actions/creating-actions/creating-a-composite-action) and [resuable workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
- Security applications, security should be handled on the policy side on the server, not decentralized on each runner
## Hooks
- We will expose 2 variables that users can set to enable hooks
-`ACTIONS_RUNNER_HOOK_JOB_STARTED`
-`ACTIONS_RUNNER_HOOK_JOB_COMPLETED`
You can set these variables to the **absolute** path of a a `.sh` or `.ps1` file.
We will execute `pwsh` (fallback to `powershell`) or `bash` (fallback to `sh`) as appropriate.
-`.sh` files will execute with the args `-e {pathtofile}`
-`.ps1` files will execute with the args `-command \". '{pathtofile}'\"`
We will **not** set the [standard flags we typically set](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell) for `runs` commands. So, if you want to set `pipefail` on `bash` for example, you will need to do that in your script.
### UI
We want to ensure the experience for users invoking workflows is good, if hooks take too long, you may feel your job is delayed or broken. So, much like `Set Up Job`, we will generate two new steps automatically in your job, one for each configured hook:
-`Set up runner`
-`Complete runner`
These steps will contain all of the output from invoking your hook, so you will have visibility into the runtime. We will also provide information on the path to the hook, and what shell we are invoking it as, much like we do for `run: ` steps.
### Contexts
When running your hooks, some context on your job may be helpful.
- The scripts will have access to the standard [default environment variables](https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables)
- Some of these variables are step specific like `GITHUB_ACTION`, in which case they will not be set
- You can pull the full webhook event payload from `GITHUB_EVENT_PATH`
### Commands
Should we expose [Commands](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions) and [Environment Files](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#environment-files)
**Yes**. Imagine a scenario where a runner administrator is deprecating a runner pool, and they need to [warn users](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-a-warning-message) to swap to a different pool, we should support them in doing this. However, there are some limitations:
- [save-state](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#sending-values-to-the-pre-and-post-actions) will **not** be supported, these are not traditional steps with pre and post actions
- [set-output](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#using-workflow-commands-to-access-toolkit-functions) will **not** be supported, there is no `id` as this is not a traditional step
### Environment Files
We will also enable [Environment Files](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#environment-files) to support setup scenarios for the runner environment.
While a self hosted runner admin can [set env variables](https://docs.github.com/en/actions/hosting-your-own-runners/using-a-proxy-server-with-self-hosted-runners#using-a-env-file-to-set-the-proxy-configuration), these apply to all jobs. By enabling the ability to `add a path` and `set an env` we give runner admins the ability to do this dynamically based on the [workflows environment variables](https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables) to empower setup scenarios.
### Exit codes
These are **synchronous** hooks, so they will block job execution while they are being run. Exit code 0 will indicate a successful run of the hook and we will proceed with the job, any other exit code will fail the job with an appropriate annotation.
- There will be no support for `continue-on-error`
## Key Decisions
- We will expose 2 variables that users can set to enable hooks
-`ACTIONS_RUNNER_HOOK_JOB_STARTED`
-`ACTIONS_RUNNER_HOOK_JOB_COMPLETED`
- Users can set these variables to the path of a `.sh` or `.ps1` file, which we will execute when Jobs are started or completed.
- Output from these will be added to a new step at the start/end of a job named `Set up runner` or `Complete runner`.
- These steps will only be generated on runs with these hooks
- These hooks `always()` execute if the env variable is set
- These files will execute as the Runner user, outside of any container specification on the job
- These are **synchronous** hooks
- Runner admins can execute a background process for async hooks if they want
- We will fail the job and halt execution on any exit code that is not 0. The Runner admin is responsible for returning the correct exit code and ensuring resilency.
- This includes that the runner user needs access to the file in the env and the file must exist
- There will be no `continue-on-error` type option on launch
- There will be no `timeout` option on launch
## Consequences
- Runner admins have the ability to tie into the runner job execution to publish their own telemetry or perform their own cleanup or setup
- New steps will be added to the UI showcasing the output of these hooks
[Job Hooks](https://github.com/actions/runner/blob/main/docs/adrs/1751-runner-job-hooks.md) have given users the ability to customize how their self hosted runners run a job.
Users also want the ability to customize how they run containers during the scope of the job, rather then being locked into the docker implementation we have in the runner. They may want to use podman, kubernetes, or even change the docker commands we run.
We should give them that option, and publish examples how how they can create their own hooks.
# Guiding Principles
- **Extensibility** is the focus, we need to make sure we are flexible enough to cover current and future scenarios, even at the cost of making it harder to utilize these hooks
- Args should map **directly** to yaml values provided by the user.
- For example, the current runner overrides `HOME`, we can do that in the hook, but we shouldn't pass that hook as an ENV with the other env's the user has set, as that is not user input, it is how the runner invokes containers
## Interface
- You will set the variable `ACTIONS_RUNNER_CONTAINER_HOOKS=/Users/foo/runner/hooks.js` which is the entrypoint to your hook handler.
- There is no partial opt in, you must handle every hook
- We will pass a command and some args via `stdin`
- An exit code of 0 is a success, every other exit code is a failure
- We will support the same runner commands we support in [Job Hooks](https://github.com/actions/runner/blob/main/docs/adrs/1751-runner-job-hooks.md)
- On timeout, we will send a sigint to your process. If you fail to terminate within a reasonable amount of time, we will send a sigkill, and eventually kill the process tree.
`responseFile` is the file you need to write your output to, if the command has output
`args` are the specific arguments the command needs
`state` is a json blog you can pass around to maintain your state, this is covered in more details below.
### Writing responses to a file
All text written to stdout or stderr should appear in the job or step logs. With that in mind, we support a few ways to actually return data:
1. Wrapping the json in some unique tag and processing it like we do commands
2. Writing to a file
For 1, users typically view logging information as a safe action, so we worry someone accidentialy logging unsantized information and causing unexpected or un-secure behavior. We eventually plan to move off of stdout/stderr style commands in favor of a runner cli.
Investing in this area doesn't make a lot of sense at this time.
While writing to a file to communicate isn't the most ideal pattern, its an existing pattern in the runner and serves us well, so lets reuse it.
### Output
Your output must be correctly formatted json. An example output looks like:
`state` is a unique field any command can return. If it is not empty, we will store the state for you and pass it into all future commands. You can overwrite it by having the next hook invoked return a unique state.
Other fields are dependent upon the command being run.
### Versioning
We will not version these hooks at launch. If needed, we can always major version split these hooks in the future. We will ship in Beta to allow for breaking changes for a few months.
### The Job Context
The [job context](https://docs.github.com/en/actions/learn-github-actions/contexts#example-contents-of-the-job-context) currently has a variety of fields that correspond to containers. We should consider allowing hooks to populate new fields in the job context. That is out of scope for this original release however.
## Hooks
Hooks are to be implemented at a very high level, and map to actions the runner does, rather then specific docker actions like `docker build` or `docker create`. By mapping to runner actions, we create a very extensible framework that is flexible enough to solve any user concerns in the future. By providing first party implementations, we give users easy starting points to customize specific hooks (like `docker build`) without having to write full blown solutions.
The other would be to provide hooks that mirror every docker call we make, and expose more hooks to help support k8s users, with the expectation that users may have to no-op on multiple hooks if they don't correspond to our use case.
Why we don't want to go that way
- It feels clunky, users need to understand which hooks they need to implement and which they can ignore, which isn't a great UX
- It doesn't scale well, I don't want to build a solution where we may need to add more hooks, by mapping to runner actions, updating hooks is a painful experience for users
- Its overwhelming, its easier to tell users to build 4 hooks and track data themselves, rather then 16 hooks where the runner needs certain information and then needs to provide that information back into each hook. If we expose `Container Create`, you need to return the container you created, then we do `container run` which uses that container. If we just give you an image and say create and run this container, you don't need to store the container id in the runner, and it maps better to k8s scenarios where we don't really have container ids.
### Prepare_job hook
The `prepare_job` hook is called when a job is started. We pass in any job or service containers the job has. We expect that you:
- Prune anything from previous jobs if needed
- Create a network if needed
- Pull the job and service containers
- Start the job container
- Start the service containers
- Write to the response file some information we need
- Required: if the container is alpine, otherwise x64
- Optional: any context fields you want to set on the job context, otherwise they will be unavailable for users to use
- Return 0 when the health checks have succeeded and the job/service containers are started
This hook will **always** be called if you have container hooks enabled, even if no service or job containers exist in the job. This allows you to fail the job or implement a default job container if you want to and no job container has been provided.
jobContainer: **Optional** An Object containing information about the specified job container
"image": **Required** A string containing the docker image
"workingDirectory": **Required** A string containing the absolute path of the working directory
"createOptions": **Optional** The optional create options specified in the [YAML](https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)
"environmentVariables": **Optional** A map of key value env's to set
"userMountVolumes: ** Optional** an array of user mount volumes set in the [YAML](https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)
"sourceVolumePath": **Required** The source path to the volume to be mounted into the docker container
"targetVolumePath": **Required** The target path to the volume to be mounted into the docker container
"readOnly": false **Required** whether or not the mount should be read only
"mountVolumes": **Required** an array of mounts to mount into the container, same fields as above
"sourceVolumePath": **Required** The source path to the volume to be mounted into the docker container
"targetVolumePath": **Required** The target path to the volume to be mounted into the docker container
"readOnly": false **Required** whether or not the mount should be read only
"registry" **Optional** docker registry credentials to use when using a private container registry
"username": **Optional** the username
"password": **Optional** the password
"serverUrl": **Optional** the registry url
"portMappings": **Optional** an array of source:target ports to map into the container
"services": an array of service containers to spin up
"contextName": **Required** the name of the service in the Job context
"image": **Required** A string containing the docker image
"createOptions": **Optional** The optional create options specified in the [YAML](https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)
"environmentVariables": **Optional** A map of key value env's to set
"mountVolumes": **Required** an array of mounts to mount into the container, same fields as above
"sourceVolumePath": **Required** The source path to the volume to be mounted into the docker container
"targetVolumePath": **Required** The target path to the volume to be mounted into the docker container
"readOnly": false **Required** whether or not the mount should be read only
"registry" **Optional** docker registry credentials to use when using a private container registry
"username": **Optional** the username
"password": **Optional** the password
"serverUrl": **Optional** the registry url
"portMappings": **Optional** an array of source:target ports to map into the container
"image": **Optional** A string containing the docker image. Otherwise a dockerfile must be provided
"dockerfile": **Optional** A string containing the path to the dockerfile, otherwise an image must be provided
"entryPointArgs": **Optional** A list containing the entry point args
"entryPoint": **Optional** The container entry point to use if the default image entrypoint should be overwritten
"workingDirectory": **Required** A string containing the absolute path of the working directory
"createOptions": **Optional** The optional create options specified in the [YAML](https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)
"environmentVariables": **Optional** A map of key value env's to set
"prependPath": **Optional** an array of additional paths to prepend to the $PATH variable
"userMountVolumes: ** Optional** an array of user mount volumes set in the [YAML](https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#example-running-a-job-within-a-container)
"sourceVolumePath": **Required** The source path to the volume to be mounted into the docker container
"targetVolumePath": **Required** The target path to the volume to be mounted into the docker container
"readOnly": false **Required** whether or not the mount should be read only
"mountVolumes": **Required** an array of mounts to mount into the container, same fields as above
"sourceVolumePath": **Required** The source path to the volume to be mounted into the docker container
"targetVolumePath": **Required** The target path to the volume to be mounted into the docker container
"readOnly": false **Required** whether or not the mount should be read only
"registry" **Optional** docker registry credentials to use when using a private container registry
"username": **Optional** the username
"password": **Optional** the password
"serverUrl": **Optional** the registry url
"portMappings": **Optional** an array of source:target ports to map into the container
```
</details>
No output is expected
Currently we build all container actions at the start of the job. By doing it during the hook, we move this to just in time building for hooks. We could expose a hook to build/pull a container action, and have those called at the start of a job, but doing so would require hook authors to track the build containers in the state, which could be painful.
### Run Script Step
The `run_script_step` expects you to:
- Invoke the provided script inside the job container and return the exit code
Following the [adoption of actions-runner-controller by GitHub](https://github.com/actions/actions-runner-controller/discussions/2072) and the introduction of the new runner scale set autoscaling mode, we needed to provide a basic runner image that could be used off the shelf without much friction.
The [current runner image](https://github.com/actions/runner/pkgs/container/actions-runner) is published to GHCR. Each release of this image is tagged with the runner version and the most recent release is also tagged with `latest`.
While the use of `latest` is common practice, we recommend that users pin a specific version of the runner image for a predictable runtime and improved security posture. However, we still notice that a large number of end users are relying on the `latest` tag & raising issues when they encounter problems.
Add to that, the community actions-runner-controller maintainers have issued a [deprecation notice](https://github.com/actions/actions-runner-controller/issues/2056) of the `latest` tag for the existing runner images (https://github.com/orgs/actions-runner-controller/packages).
## Decision
Proceed with Option 2, keeping the `latest` tag and adding the `NOTES.txt` file to our helm charts with the notice.
### Option 1: Remove the `latest` tag
By removing the `latest` tag, we have to proceed with either of these options:
1. Remove the runner image reference in the `values.yaml` provided with the `gha-runner-scale-set` helm chart and mark these fields as required so that users have to explicitly specify a runner image and a specific tag. This will obviously introduce more friction for users who want to start using actions-runner-controller for the first time.
```yaml
spec:
containers:
- name:runner
image:""
tag:""
command:["/home/runner/run.sh"]
```
1. Pin a specific runner image tag in the `values.yaml` provided with the `gha-runner-scale-set` helm chart. This will reduce friction for users who want to start using actions-runner-controller for the first time but will require us to update the `values.yaml` with every new runner release.
```yaml
spec:
containers:
- name:runner
image:"ghcr.io/actions/actions-runner"
tag:"v2.300.0"
command:["/home/runner/run.sh"]
```
### Option 2: Keep the `latest` tag
Keeping the `latest` tag is also a reasonable option especially if we don't expect to make any breaking changes to the runner image. We could enhance this by adding a [NOTES.txt](https://helm.sh/docs/chart_template_guide/notes_files/) to the helm chart which will be displayed to the user after a successful helm install/upgrade. This will help users understand the implications of using the `latest` tag and how to pin a specific version of the runner image.
The runner image release workflow will need to be updated so that the image is pushed to GHCR and tagged only when the runner rollout has reached all scale units.
## Consequences
Proceeding with **option 1** means:
1. We will enhance the runtime predictability and security posture of our end users
1. We will have to update the `values.yaml` with every new runner release (that can be automated)
1. We will introduce friction for users who want to start using actions-runner-controller for the first time
Proceeding with **option 2** means:
1. We will have to continue to maintain the `latest` tag
1. We will assume that end users will be able to handle the implications of using the `latest` tag
1. Runner image release workflow needs to be updated
Make sure the runner has access to actions service for GitHub.com or GitHub Enterprise Server
- For GitHub.com
- The runner needs to access https://api.github.com for downloading actions.
- The runner needs to access https://vstoken.actions.githubusercontent.com/_apis/.../ for requesting an access token.
- The runner needs to access https://pipelines.actions.githubusercontent.com/_apis/.../ for receiving workflow jobs.
- The runner needs to access `https://api.github.com` for downloading actions.
- The runner needs to access `https://codeload.github.com` for downloading actions tar.gz/zip.
- The runner needs to access `https://vstoken.actions.githubusercontent.com/_apis/.../` for requesting an access token.
- The runner needs to access `https://pipelines.actions.githubusercontent.com/_apis/.../` for receiving workflow jobs.
- The runner needs to access `https://results-receiver.actions.githubusercontent.com/.../` for reporting progress and uploading logs during a workflow job execution.
---
**NOTE:** for the full list of domains that are required to be in the firewall allow list refer to the [GitHub self-hosted runners requirements documentation](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#communication-between-self-hosted-runners-and-github).
These can by tested by running the following `curl` commands from your self-hosted runner machine:
- The runner needs to access https://myGHES.com/api/v3 for downloading actions.
- The runner needs to access https://myGHES.com/_services/vstoken/_apis/.../ for requesting an access token.
- The runner needs to access https://myGHES.com/_services/pipelines/_apis/.../ for receiving workflow jobs.
- The runner needs to access `https://[hostname]/api/v3` for downloading actions.
- The runner needs to access `https://codeload.[hostname]/_ping` for downloading actions tar.gz/zip.
- The runner needs to access `https://[hostname]/_services/vstoken/_apis/.../` for requesting an access token.
- The runner needs to access `https://[hostname]/_services/pipelines/_apis/.../` for receiving workflow jobs.
These can by tested by running the following `curl` commands from your self-hosted runner machine, replacing `[hostname]` with the hostname of your appliance, for instance `github.example.com`:
A common cause of this these connectivity issues is if your to GitHub Enterprise Server appliance is using [the self-signed certificate that is enabled the first time](https://docs.github.com/en/enterprise-server/admin/configuration/configuring-network-settings/configuring-tls) your appliance is started. As self-signed certificates are not trusted by web browsers and Git clients, these clients (including the GitHub Actions runner) will report certificate warnings.
We recommend [upload a certificate signed by a trusted authority](https://docs.github.com/en/enterprise-server/admin/configuration/configuring-network-settings/configuring-tls) to GitHub Enterprise Server, or enabling the built-in ][Let's Encrypt support](https://docs.github.com/en/enterprise-server/admin/configuration/configuring-network-settings/configuring-tls).
## What is checked?
@@ -20,6 +50,10 @@ Make sure the runner has access to actions service for GitHub.com or GitHub Ente
- Ping api.github.com or myGHES.com using dotnet
- Make HTTP GET to https://api.github.com or https://myGHES.com/api/v3 using dotnet, check response headers contains `X-GitHub-Request-Id`
---
- DNS lookup for codeload.github.com or codeload.myGHES.com using dotnet
- Ping codeload.github.com or codeload.myGHES.com using dotnet
- Make HTTP GET to https://codeload.github.com/_ping or https://codeload.myGHES.com/_ping using dotnet, check response headers contains `X-GitHub-Request-Id`
---
- DNS lookup for vstoken.actions.githubusercontent.com using dotnet
- Ping vstoken.actions.githubusercontent.com using dotnet
- Make HTTP GET to https://vstoken.actions.githubusercontent.com/_apis/health or https://myGHES.com/_services/vstoken/_apis/health using dotnet, check response headers contains `x-vss-e2eid`
@@ -28,6 +62,10 @@ Make sure the runner has access to actions service for GitHub.com or GitHub Ente
- Ping pipelines.actions.githubusercontent.com using dotnet
- Make HTTP GET to https://pipelines.actions.githubusercontent.com/_apis/health or https://myGHES.com/_services/pipelines/_apis/health using dotnet, check response headers contains `x-vss-e2eid`
- Make HTTP POST to https://pipelines.actions.githubusercontent.com/_apis/health or https://myGHES.com/_services/pipelines/_apis/health using dotnet, check response headers contains `x-vss-e2eid`
---
- DNS lookup for results-receiver.actions.githubusercontent.com using dotnet
- Ping results-receiver.actions.githubusercontent.com using dotnet
- Make HTTP GET to https://results-receiver.actions.githubusercontent.com/health using dotnet, check response headers contains `X-GitHub-Request-Id`
## How to fix the issue?
@@ -42,4 +80,4 @@ Make sure the runner has access to actions service for GitHub.com or GitHub Ente
## Still not working?
Contact GitHub customer service or log an issue at https://github.com/actions/runner if you think it's a runner issue.
Contact [GitHub Support](https://support.github.com) if you have further questuons, or log an issue at https://github.com/actions/runner if you think it's a runner issue.
@@ -20,11 +20,30 @@ The test also set environment variable `GIT_TRACE=1` and `GIT_CURL_VERBOSE=1` be
## How to fix the issue?
### 1. Check the common network issue
### 1. Check global and system git config
If you are having issues connecting to the server, check your global and system git config for any unexpected authentication headers. You might be seeing an error like:
```
fatal: unable to access 'https://github.com/actions/checkout/': The requested URL returned error: 400
```
The following commands can be used to check for unexpected authentication headers:
- A Proxy may try to modify the HTTPS request (like add or change some http headers) and causes the request become incompatible with the Actions Service (ASP.NetCore), Ex: [Nginx](https://github.com/dotnet/aspnetcore/issues/17081)
- Firewall rules that block action runner from accessing certain hosts, ex: `*.github.com`, `*.actions.githubusercontent.com`, etc
- Firewall rules that block action runner from accessing [certain hosts](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#communication-between-self-hosted-runners-and-github), ex: `*.github.com`, `*.actions.githubusercontent.com`, etc
### Identify and solve these problems
@@ -42,6 +42,7 @@ If you are having trouble connecting, try these steps:
We welcome contributions in the form of issues and pull requests. We view the contributions and the process as the same for github and external contributors.
We welcome contributions in the form of issues and pull requests. We view the contributions and the process as the same for github and external contributors.Please note the runner typically requires changes across the entire system and we aim for issues in the runner to be entirely self contained and fixable here. Therefore, we will primarily handle bug issues opened in this repo and we kindly request you to create all feature and enhancement requests on the [GitHub Feedback](https://github.com/community/community/discussions/categories/actions-and-packages) page.
> IMPORTANT: Building your own runner is critical for the dev inner loop process when contributing changes. However, only runners built and distributed by GitHub (releases) are supported in production. Be aware that workflows and orchestrations run service side with the runner being a remote process to run steps. For that reason, the service can pull the runner forward so customizations can be lost.
@@ -23,6 +23,12 @@ An ADR is an Architectural Decision Record. This allows consensus on the direct
  Git for Windows and Linux [Install Here](https://git-scm.com/downloads) (needed for dev sh script)
 cURL [Install here](https://curl.se/download.html) (needed for external sh script)
 Visual Studio 2017 or newer [Install here](https://visualstudio.microsoft.com) (needed for dev sh script)
 Visual Studio 2022 17.3 Preview or later. [Install here](https://docs.microsoft.com/en-us/visualstudio/releases/2022/release-notes-preview)
## Quickstart: Run a job from a real repository
If you just want to get from building the sourcecode to using it to execute an action, you will need:
Please see "[Supported architectures and operating systems for self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#linux)."
## Install .Net Core 3.x Linux Dependencies
@@ -23,8 +14,8 @@ You might see something like this which indicate a dependency's missing.
./config.sh
libunwind.so.8 => not found
libunwind-x86_64.so.8 => not found
Dependencies is missing for Dotnet Core 3.0
Execute ./bin/installdependencies.sh to install any missing Dotnet Core 3.0 dependencies.
Dependencies is missing for Dotnet Core 6.0
Execute ./bin/installdependencies.sh to install any missing Dotnet Core 6.0 dependencies.
```
You can easily correct the problem by executing `./bin/installdependencies.sh`.
The `installdependencies.sh` script should install all required dependencies on all supported Linux versions
@@ -34,7 +25,7 @@ The `installdependencies.sh` script should install all required dependencies on
The runner is currently not supported on devices with an Apple M1 chip.
We are waiting for official .NET support. You can read more here about the [current state of support here](https://github.com/orgs/dotnet/projects/18#card-56812463).
Please see "[Supported architectures and operating systems for self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#macos)."
Please see "[Supported architectures and operating systems for self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#windows)."
_Note: Actions Runner follows a progressive release policy, so the latest release might not be available to your enterprise, organization, or repository yet.
To confirm which version of the Actions Runner you should expect, please view the download instructions for your enterprise, organization, or repository.
See https://docs.github.com/en/enterprise-cloud@latest/actions/hosting-your-own-runners/adding-self-hosted-runners_
## Windows x64
We recommend configuring the runner in a root folder of the Windows drive (e.g. "C:\actions-runner"). This will help avoid issues related to service identity folder permissions and long file path restrictions on Windows.
The following snipped needs to be run on `powershell`:
**Warning:** Windows arm64 runners are currently in preview status and use [unofficial versions of nodejs](https://unofficial-builds.nodejs.org/). They are not intended for production workflows.
We recommend configuring the runner in a root folder of the Windows drive (e.g. "C:\actions-runner"). This will help avoid issues related to service identity folder permissions and long file path restrictions on Windows.
The following snipped needs to be run on `powershell`:
tar xzf ./actions-runner-osx-arm64-<RUNNER_VERSION>.tar.gz
```
## Linux x64
``` bash
```bash
# Create a folder
mkdir actions-runner &&cd actions-runner
# Download the latest runner package
@@ -44,7 +77,7 @@ tar xzf ./actions-runner-linux-x64-<RUNNER_VERSION>.tar.gz
## Linux arm64
``` bash
```bash
# Create a folder
mkdir actions-runner &&cd actions-runner
# Download the latest runner package
@@ -55,7 +88,7 @@ tar xzf ./actions-runner-linux-arm64-<RUNNER_VERSION>.tar.gz
## Linux arm
``` bash
```bash
# Create a folder
mkdir actions-runner &&cd actions-runner
# Download the latest runner package
@@ -65,6 +98,7 @@ tar xzf ./actions-runner-linux-arm-<RUNNER_VERSION>.tar.gz
```
## Using your self hosted runner
For additional details about configuring, running, or shutting down the runner please check out our [product docs.](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/adding-self-hosted-runners)
## SHA-256 Checksums
@@ -72,7 +106,9 @@ For additional details about configuring, running, or shutting down the runner p
The SHA-256 checksums for the packages included in this build are shown below:
- actions-runner-win-x64-<RUNNER_VERSION>.zip <!-- BEGIN SHA win-x64 --><WIN_X64_SHA><!-- END SHA win-x64 -->
- actions-runner-win-arm64-<RUNNER_VERSION>.zip <!-- BEGIN SHA win-arm64 --><WIN_ARM64_SHA><!-- END SHA win-arm64 -->
- actions-runner-osx-x64-<RUNNER_VERSION>.tar.gz <!-- BEGIN SHA osx-x64 --><OSX_X64_SHA><!-- END SHA osx-x64 -->
- actions-runner-osx-arm64-<RUNNER_VERSION>.tar.gz <!-- BEGIN SHA osx-arm64 --><OSX_ARM64_SHA><!-- END SHA osx-arm64 -->
- actions-runner-linux-x64-<RUNNER_VERSION>.tar.gz <!-- BEGIN SHA linux-x64 --><LINUX_X64_SHA><!-- END SHA linux-x64 -->
- actions-runner-linux-arm64-<RUNNER_VERSION>.tar.gz <!-- BEGIN SHA linux-arm64 --><LINUX_ARM64_SHA><!-- END SHA linux-arm64 -->
- actions-runner-linux-arm-<RUNNER_VERSION>.tar.gz <!-- BEGIN SHA linux-arm --><LINUX_ARM_SHA><!-- END SHA linux-arm -->
if [ $user_id -eq 0 -a -z "$RUNNER_ALLOW_RUNASROOT" ]; then
echo "Must not run interactively with sudo"
exit 1
fi
# Run
shopt -s nocasematch
SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
SOURCE="$(readlink "$SOURCE")"
[[ $SOURCE != /* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
# Wait for docker to start
if [ ! -z "$RUNNER_WAIT_FOR_DOCKER_IN_SECONDS" ]; then
if [ "$RUNNER_WAIT_FOR_DOCKER_IN_SECONDS" -gt 0 ]; then
echo "Waiting for docker to be ready."
for i in $(seq "$RUNNER_WAIT_FOR_DOCKER_IN_SECONDS"); do
if docker ps > /dev/null 2>&1; then
echo "Docker is ready."
break
fi
"$DIR"/safe_sleep.sh 1
done
fi
fi
updateFile="update.finished"
"$DIR"/bin/Runner.Listener run $*
returnCode=$?
if [[ $returnCode == 0 ]]; then
echo "Runner listener exit with 0 return code, stop the service, no retry needed."
exit 0
elif [[ $returnCode == 1 ]]; then
echo "Runner listener exit with terminated error, stop the service, no retry needed."
exit 0
elif [[ $returnCode == 2 ]]; then
echo "Runner listener exit with retryable error, re-launch runner in 5 seconds."
"$DIR"/safe_sleep.sh 5
exit 2
elif [[ $returnCode == 3 ]]; then
# Wait for 30 seconds or for flag file to exists for the runner update process finish
echo "Runner listener exit because of updating, re-launch runner after successful update"
for i in {0..30}; do
if test -f "$updateFile"; then
echo "Update finished successfully."
rm "$updateFile"
break
fi
"$DIR"/safe_sleep.sh 1
done
exit 2
elif [[ $returnCode == 4 ]]; then
# Wait for 30 seconds or for flag file to exists for the ephemeral runner update process finish
echo "Runner listener exit because of updating, re-launch runner after successful update"
for i in {0..30}; do
if test -f "$updateFile"; then
echo "Update finished successfully."
rm "$updateFile"
break
fi
"$DIR"/safe_sleep.sh 1
done
exit 2
elif [[ $returnCode == 5 ]]; then
echo "Runner listener exit with Session Conflict error, stop the service, no retry needed."
exit 0
else
echo "Exiting with unknown error code: ${returnCode}"
while[ -h "$SOURCE"];do# resolve $SOURCE until the file is no longer a symlink
DIR="$(cd -P "$( dirname "$SOURCE")"&&pwd)"
SOURCE="$(readlink "$SOURCE")"
[[$SOURCE != /* ]]&&SOURCE="$DIR/$SOURCE"# if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
DIR="$(cd -P "$( dirname "$SOURCE")"&&pwd)"
SOURCE="$(readlink "$SOURCE")"
[[$SOURCE != /* ]]&&SOURCE="$DIR/$SOURCE"# if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$(cd -P "$( dirname "$SOURCE")"&&pwd)"
# Do not "cd $DIR". For localRun, the current directory is expected to be the repo location on disk.
# Run
shopt -s nocasematch
if[["$1"=="localRun"]];then
"$DIR"/bin/Runner.Listener$*
else
"$DIR"/bin/Runner.Listener run $*
# Return code 3 means the run once runner received an update message.
# Sleep 5 seconds to wait for the update process finish
returnCode=$?
if[[$returnCode==3]];then
if[ ! -x "$(command -v sleep)"];then
if[ ! -x "$(command -v ping)"];then
COUNT="0"
while[[$COUNT !=5000]];do
echo"SLEEP" > /dev/null
COUNT=$[$COUNT+1]
done
else
ping -c 5 127.0.0.1 > /dev/null
fi
run(){
# run the helper process which keep the listener alive
echo"Warning: failed to update certificate store: update-ca-certificates or update-ca-trust not found. This can happen if you're using a different runner base image."
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.