rebase from github

.github/workflows/build.yml

@@ -1,6 +1,7 @@
 name: Runner CI
 
 on:
+  workflow_dispatch:
   push:
     branches:
     - master

.github/workflows/codeql.yml

@@ -0,0 +1,35 @@
+name: "Code Scanning - Action"
+
+on:
+  push:
+  schedule:
+    - cron: '0 0 * * 0'
+
+jobs:
+  CodeQL-Build:
+
+    strategy:
+      fail-fast: false
+
+
+    # CodeQL runs on ubuntu-latest, windows-latest, and macos-latest
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout repository
+      uses: actions/checkout@v2
+
+    # Initializes the CodeQL tools for scanning.
+    - name: Initialize CodeQL
+      uses: github/codeql-action/init@v1
+      # Override language selection by uncommenting this and choosing your languages
+      # with:
+      #   languages: go, javascript, csharp, python, cpp, java
+
+    - name: Manual build
+      run : | 
+        ./dev.sh layout Release linux-x64
+      working-directory: src
+
+    - name: Perform CodeQL Analysis
+      uses: github/codeql-action/analyze@v1

docs/adrs/0274-step-outcome-and-conclusion.md

@@ -0,0 +1,62 @@
+# ADR 0274: Step outcome and conclusion
+
+**Date**: 2020-01-13
+
+**Status**: Accepted
+
+## Context
+
+This ADR proposes adding `steps.<id>.outcome` and `steps.<id>.conclusion` to the steps context.
+
+This allows downstream a step to run based on whether a previous step succeeded or failed.
+
+Reminder, currently the steps contains `steps.<id>.outputs`.
+
+## Decision
+
+For steps that have completed, populate `steps.<id>.outcome` and `steps.<id>.conclusion` with one of the following values:
+
+- `success`
+- `failure`
+- `cancelled`
+- `skipped`
+
+When a continue-on-error step fails, the outcome will be `failure` even though the final conclusion is `success`.
+
+### Example
+
+```yaml
+steps:
+
+  - id: experimental
+    continue-on-error: true
+    run: ./build.sh experimental
+
+  - if: ${{ steps.experimental.outcome == 'success' }}
+    run: ./publish.sh experimental
+```
+
+### Terminology
+
+The runs API uses the term `conclusion`.
+
+Therefore we use a different term `outcome` for the value prior to continue-on-error.
+
+The following is a snippet from the runs API response payload:
+
+```json
+      "steps": [
+        {
+          "name": "Set up job",
+          "status": "completed",
+          "conclusion": "success",
+          "number": 1,
+          "started_at": "2020-01-09T11:06:16.000-05:00",
+          "completed_at": "2020-01-09T11:06:18.000-05:00"
+        },
+```
+
+## Consequences
+
+- Update runner
+- Update [docs](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#steps-context)

docs/adrs/0361-wrapper-action.md

@@ -0,0 +1,75 @@
+# ADR 361: Wrapper Action
+
+**Date**: 2020-03-06
+
+**Status**: Pending
+
+## Context
+
+In addition to action's regular execution, action author may wants their action has a chance to participate in:
+- Job initialize  
+  My Action will collect machine resource usage (CPU/RAM/Disk) during a workflow job execution, we need to start perf recorder at the begin of the job.
+- Job cleanup  
+  My Action will dirty local workspace or machine environment during execution, we need to cleanup these changes at the end of the job.  
+  Ex: `actions/checkout@v2` will write `github.token` into local `.git/config` during execution, it has post job cleanup defined to undo the changes.
+
+## Decision
+
+### Add `pre` and `post` execution to action
+
+Node Action Example:
+
+```yaml
+ name: 'My action with pre'
+ description: 'My action with pre'
+ runs:
+   using: 'node12'
+   pre: 'setup.js'
+   pre-if: 'success()' // Optional
+   main: 'index.js'
+   post: 'cleanup.js'
+   post-if: 'success()' // Optional
+```
+
+Container Action Example:
+
+```yaml
+ name: 'My action with pre'
+ description: 'My action with pre'
+ runs:
+   using: 'docker'
+   image: 'mycontainer:latest'
+   pre-entrypoint: 'setup.sh'
+   pre-if: 'success()' // Optional
+   entrypoint: 'entrypoint.sh'
+   post-entrypoint: 'cleanup.sh'
+   post-if: 'success()' // Optional
+```
+
+Both `pre` and `post` will has default `pre-if/post-if` sets to `always()`.  
+Setting `pre` to `always()` will make sure no matter what condition evaluate result the `main` gets at runtime, the `pre` has always run already.   
+`pre` executes in order of how the steps are defined.  
+`pre` will always be added to job steps list during job setup.  
+> Action referenced from local repository (`./my-action`) won't get `pre` setup correctly since the repository haven't checkout during job initialize.  
+> We can't use GitHub api to download the repository since there is a about 3 mins delay between `git push` and the new commit available to download using GitHub api.
+
+`post` will be pushed into a `poststeps` stack lazily when the action's `pre` or `main` execution passed `if` condition check and about to run, you can't have an action that only contains a `post`, we will pop and run each `post` after all `pre` and `main` finished.
+> Currently `post` works for both repository action (`org/repo@v1`) and local action (`./my-action`)
+
+Valid action:
+- only has `main`
+- has `pre` and `main`
+- has `main` and `post`
+- has `pre`, `main` and `post`
+
+Invalid action:
+- only has `pre`
+- only has `post`
+- has `pre` and `post`
+
+Potential downside of introducing `pre`:
+
+- Extra magic wrt step order. Users should control the step order. Especially when we introduce templates.  
+- Eliminates the possibility to lazily download the action tarball, since `pre` always run by default, we have to download the tarball to check whether action defined a `pre`  
+- `pre` doesn't work with local action, we suggested customer use local action for testing their action changes, ex CI for their action, to avoid delay between `git push` and GitHub repo tarball download api.  
+- Condition on the `pre` can't be controlled using dynamic step outputs. `pre` executes too early.

docs/adrs/0397-runner-registration-labels.md

@@ -0,0 +1,56 @@
+# ADR 0397: Support adding custom labels during runner config
+**Date**: 2020-03-30
+
+**Status**: Approved
+
+## Context
+
+Since configuring self-hosted runners is commonly automated via scripts, the labels need to be able to be created during configuration.  The runner currently registers the built-in labels (os, arch) during registration but does not accept labels via command line args to extend the set registered.
+
+See Issue: https://github.com/actions/runner/issues/262
+
+This is another version of [ADR275](https://github.com/actions/runner/pull/275)
+
+## Decision
+
+This ADR proposes that we add a `--labels` option to `config`, which could be used to add custom additional labels to the configured runner.
+
+For example, to add a single extra label the operator could run:
+```bash
+./config.sh --labels mylabel
+```
+> Note: the current runner command line parsing and envvar override algorithm only supports a single argument (key).
+
+This would add the label `mylabel` to the runner, and enable users to select the runner in their workflow using this label:
+```yaml
+runs-on: [self-hosted, mylabel]
+```
+
+To add multiple labels the operator could run:
+```bash
+./config.sh --labels mylabel,anotherlabel
+```
+> Note: the current runner command line parsing and envvar override algorithm only supports a single argument (key).
+
+This would add the label `mylabel` and `anotherlabel` to the runner, and enable users to select the runner in their workflow using this label:
+```yaml
+runs-on: [self-hosted, mylabel, anotherlabel]
+```
+
+It would not be possible to remove labels from an existing runner using `config.sh`, instead labels would have to be removed using the GitHub UI.
+
+The labels argument will split on commas, trim and discard empty strings.  That effectively means don't use commans in unattended config label names.  Alternatively we could choose to escape commans but it's a nice to have.
+
+## Replace
+
+If an existing runner exists and the option to replace is chosen (interactively of via unattend as in this scenario), then the labels will be replaced / overwritten (not merged).
+
+## Overriding built-in labels
+
+Note that it is possible to register "built-in" hosted labels like `ubuntu-latest` and is not considered an error.  This is an effective way for the org / runner admin to dictate by policy through registration that this set of runners will be used without having to edit all the workflow files now and in the future.
+
+We will also not make other restrictions such as limiting explicitly adding os / arch labels and validating.  We will assume that explicit labels were added for a reason and not restricting offers the most flexibility and future proofing / compat.
+
+## Consequences
+
+The ability to add custom labels to a self-hosted runner would enable most scenarios where job runner selection based on runner capabilities or characteristics are required.