* Secure workflows (#1) (#1072)
* Restrict permissions for the GITHUB_TOKEN in .github/workflows/label-feature.yml
* Restrict permissions for the GITHUB_TOKEN in .github/workflows/label-support.yml
* Restrict permissions for the GITHUB_TOKEN in .github/workflows/stale.yml
* Restrict permissions for the GITHUB_TOKEN in .github/workflows/sync_ghes.yaml
* Restrict permissions for the GITHUB_TOKEN in .github/workflows/validate-data.yaml
Co-authored-by: Step Security <bot@stepsecurity.io>
Co-authored-by: step-security[bot] <89328102+step-security[bot]@users.noreply.github.com>
Co-authored-by: Step Security <bot@stepsecurity.io>
* Directory for deployments (#1071)
* moving deployment templates
* including deployment directory in scripts
* validate categories script init
* introducing scout
* introducing workflow
* Update validate-categories.yaml
* Update validate-categories.yaml
* Update validate-categories.yaml
* Update validate.rb
* Update validate.rb
* Update validate.rb
* Update validate.rb
* Update validate-categories.yaml
* Update validate-categories.yaml
* Update validate-categories.yaml
* Update validate.rb
* Update validate-categories.yaml
* Update validate-categories.yaml
* Create test_comment.yaml
* rename
* using [enter]
* testing newline
* test
* setting up variable
* using echo -e
* using join
* testing space space new line
* setting multi line in echo
* removing checkout
* setting rows-generator
* fixing error
* using join
* commit
* Update test_comment.yaml
* escaping pipe
* printing debug line
* using %0A
* Update validate-categories.yaml
* Update validate.rb
* Update validate.rb
* removing debug
* removing variable
* Update validate.rb
* Update validate-categories.yaml
* Validate categories comment on pr (#32)
* reverting deployment directory
* checking for output
* Categories validation two workflows (#34)
comment on pr in a separate workflow
* Categories validation two workflows (#35)
using right dir name
* Categories validation two workflows (#36)
.
* Categories validation two workflows (#37)
fixing typo
* adding if conditions
* adding try catch
* using console instead of echo
* equating to upstream
* moving deployment templates
* add codeql workflow to ghes
* restoring from main (#1078)
* Revert "add codeql workflow to ghes branch"
* add codeql workflow to ghes
* only run ghes sync checks on YML files
* only check nwo of supported actions
* added `React` and `Angular` as categories to node (#1084)
* Fixed a broken link to actions/upload-a-build-artifact in dotnet-desktop.yml. (#1074)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Added support for Java Frameworks, Spring and JSF to CI Templates. (#1087)
* Update OpenShift workflow to use GHCR by default (#6)
- Simplifies required configuration since a registry account is now
optional
- Update a variety of comments
- Use tools-installer to install oc
- Other small changes towards a better UX
Signed-off-by: Tim Etchells <tetchel@gmail.com>
* Update github-script major version
Co-authored-by: John Bohannon <imjohnbo@github.com>
* Addressing review comments - Renaming template and updating setup-ruby action version (#1086)
* renaming template and updating setup-ruby action version
* renaming rubyrails files
* renaming rails files
* Addition to categories to python templates (#1088)
* addition to categories for python-app template
* adding categories to pylint template
* adding categories to python-package template
Co-authored-by: Ashwin Sangem <ashwinsangem@github.com>
* Adding category in the template property file (#1092)
* adding category in the template property file
* added category on ruby template
* add `makefile` template (#1093)
Co-authored-by: Ashwin Sangem <ashwinsangem@github.com>
* added prefix `npm-` (#1097)
* support `AspNetCore` and `DotNetConsole` (#1096)
Co-authored-by: Ashwin Sangem <ashwinsangem@github.com>
* add `Continuous integration` to makefile props (#1100)
Co-authored-by: Varun Sharma <varunsh@stepsecurity.io>
Co-authored-by: step-security[bot] <89328102+step-security[bot]@users.noreply.github.com>
Co-authored-by: Step Security <bot@stepsecurity.io>
Co-authored-by: Aparna Ravindra <82894348+aparna-ravindra@users.noreply.github.com>
Co-authored-by: Nick Fyson <nickfyson@github.com>
Co-authored-by: Ninad Kavimandan <ninadkavimandan@github.com>
Co-authored-by: tmash06 <tmash06@gmail.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Tim Etchells <tetchel@gmail.com>
Co-authored-by: Tim Etchells <tetchell@redhat.com>
Co-authored-by: John Bohannon <imjohnbo@github.com>
Co-authored-by: Shubham Tiwari <64764738+tiwarishub@users.noreply.github.com>
This PR adds a descriptive comment int "stale.yml" so user know what this does and how adjust.
This can be helpful because user's can come to this workflow as a template
directly from their issue page and this extra content will help them understand what is this.
Fixes: The actions/checkout action on windows checks out files with \r\n line endings instead of preserving them. This causes deno fmt --check to fail because the line endings are \r\n instead of \n. Instead of working around this problem specifically on Windows, this change removes the matrix in order to simplify the action.
Co-authored-by: Josh Gross <joshmgross@github.com>
There was a mistake in [last commit](https://github.com/actions/starter-workflows/commit/5ac32fc0977190a464c62c63cad5fcb04067c34e), that added additional *`* which causes this error
```
/Users/runner/work/_temp/2259bec8-2d05-441b-ada0-fad594134af2.sh: line 5: unexpected EOF while looking for matching ``'
14
Error: Process completed with exit code 2.
```
I just simply removed it.
* switch to official denoland/setup-deno action
Also adds formatting and linting to the workflow (like dart workflow), and use uniform capitalization.
* update commit hash
Co-authored-by: Josh Gross <joshmgross@github.com>
* Update dart.yml
Update Dart starter workflow to use `setup-dart` from the Dart team. This enables testing on more operating systems (Linux, Windows, and macOS), and offers more control over the Dart SDK version to test with.
* Update dart.yml
Add required disclaimer
* Update ci/dart.yml
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
github.com/actions/setup-elixir is no longer maintained and now suggests using github.com/erlef/setup-elixir
This should be updated to help new Github Actions users to use the supported action.
This enhances and cleans the previous workflow by:
- Using the universal cmake commands
- Using `${{env.BUILD_TYPE}}` instead of enforcing bash shell
- Adding the install and artifact steps
This repository contains configuration for what users see when they click on the `Actions` tab and the setup page for Code Scanning.
It is not:
* A playground to try out scripts
* A place for you to create a workflow for your repository
-->
## Pre-requisites
- [ ] Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: [partner.github.com/apply](https://partner.github.com/apply?partnershipType=Technology+Partner).
---
**Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.**
### **Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.**
---
In the workflow and properties files:
## Tasks
- [ ] The workflow filename of CI workflows should be the name of the language or platform, in lower case. Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
**For _all_ workflows, the workflow:**
The workflow filename of publishing workflows should be the name of the language or platform, in lower case, followed by "-publish".
- [ ]Includes a matching `ci/properties/*.properties.json` file.
- [ ]Use sentence case for the names of workflows and steps, for example "Run tests".
- [ ]The name of CI workflows should only be the name of the language or platform: for example "Go" (not "Go CI" or "Go Build")
- [ ] Include comments in the workflow for any parts that are not obvious or could use clarification.
- [ ]CI workflows should run on `push` to `branches: [ $default-branch ]` and `pull_request` to `branches: [ $default-branch ]`.
- [ ] Should be contained in a `.yml` file with the language or platform as its filename, in lower, [_kebab-cased_](https://en.wikipedia.org/wiki/Kebab_case) format (for example, [`docker-image.yml`](https://github.com/actions/starter-workflows/blob/main/ci/docker-image.yml)). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
- [ ]Should use sentence case for the names of workflows and steps (for example, "Run tests").
- [ ]Should be named _only_ by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
- [ ]Should include comments in the workflow for any parts that are not obvious or could use clarification.
**For _CI_ workflows, the workflow:**
- [ ] Should be preserved under [the `ci` directory](https://github.com/actions/starter-workflows/tree/main/ci).
- [ ] Should include a matching `ci/properties/*.properties.json` file (for example, [`ci/properties/docker-publish.properties.json`](https://github.com/actions/starter-workflows/blob/main/ci/properties/docker-publish.properties.json)).
- [ ] Should run on `push` to `branches: [ $default-branch ]` and `pull_request` to `branches: [ $default-branch ]`.
- [ ] Packaging workflows should run on `release` with `types: [ created ]`.
- [ ]Code Scanning workflows should run on `push` to `branches: [ $default-branch, $protected-branches ]` and `pull_request` to `branches: [ $default-branch ]`. We also recommend a `schedule` trigger of `cron: $cron-weekly`.
- [ ]Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, [`docker-publish.yml`](https://github.com/actions/starter-workflows/blob/main/ci/docker-publish.yml)).
Some general notes:
**For _Code Scanning_ workflows, the workflow:**
- [ ]This workflow must only use actions that are produced by GitHub, [in the `actions` organization](https://github.com/actions), **or**
- [ ]This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be [published to the GitHub Marketplace](https://github.com/marketplace?type=actions). We recommend that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:
- [ ]Should be preserved under [the `code-scanning` directory](https://github.com/actions/starter-workflows/tree/main/ci).
- [ ]Should include a matching `code-scanning/properties/*.properties.json` file (for example, [`code-scanning/properties/codeql.properties.json`](https://github.com/actions/starter-workflows/blob/main/code-scanning/properties/codeql.properties.json)), with properties set as follows:
- [ ]`name`: Name of the Code Scanning integration.
- [ ]`organization`: Name of the organization producing the Code Scanning integration.
- [ ]`description`: Short description of the Code Scanning integration.
- [ ]`categories`: Array of languages supported by the Code Scanning integration.
- [ ]`iconName`: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in [the `icons` directory](https://github.com/actions/starter-workflows/tree/main/icons).
- [ ] Should run on `push` to `branches: [ $default-branch, $protected-branches ]` and `pull_request` to `branches: [ $default-branch ]`. We also recommend a `schedule` trigger of `cron: $cron-weekly` (for example, [`codeql.yml`](https://github.com/actions/starter-workflows/blob/c59b62dee0eae1f9f368b7011cf05c2fc42cf084/code-scanning/codeql.yml#L14-L21)).
**Some general notes:**
- [ ] This workflow must _only_ use actions that are produced by GitHub, [in the `actions` organization](https://github.com/actions), **or**
- [ ] This workflow must _only_ use actions that are produced by the language or ecosystem that the workflow supports. These actions must be [published to the GitHub Marketplace](https://github.com/marketplace?type=actions). We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:
```
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
@@ -19,6 +19,6 @@ Before merging a new workflow, the following requirements need to be met:
- There are many programming languages and tools out there. Right now we don't have a page that allows for a really large number of workflows, so we do have to be a little choosy about what we accept. Less popular tools or languages might not be accepted.
- Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
- Automation and CI workflows cannot be dependent on a paid service or product.
- We recommend that Actions outside of the `actions` organization be pinned to a specific SHA.
- We require that Actions outside of the `actions` organization be pinned to a specific SHA.
* [ci](ci): solutions for Continuous Integration and Deployments
* [automation](automation): solutions for automating workflows.
* [code-scanning](code-scanning): starter workflows for [Code Scanning](https://github.com/features/security)
* [icons](icons): svg icons for the relevant template
@@ -20,8 +21,28 @@ Each workflow must be written in YAML and have a `.yml` extension. They also nee
For example: `ci/django.yml` and `ci/properties/django.properties.json`.
**Valid properties:**
*`name`: the name shown in onboarding
### Valid properties
*`name`: the name shown in onboarding. This property is unique within the repository.
*`description`: the description shown in onboarding
*`iconName`: the icon name in the relevant folder, for example `django` should have an icon `icons/django.svg`. Only SVG is supported at this time
*`categories`: the categories that it will be shown under
*`iconName`: the icon name in the relevant folder, for example,`django` should have an icon `icons/django.svg`. Only SVG is supported at this time. Another option is to use [octicon](https://primer.style/octicons/). The format to use an octicon is `octicon <<icon name>>`. Example: `octicon person`
*`creator`: creator of the template shown in onboarding. All the workflow templates from an author will have the same `creator` field.
*`categories`: the categories that it will be shown under. Choose at least one category from the list [here](#categories). Further, choose the categories from the list of languages available [here](https://github.com/github/linguist/blob/master/lib/linguist/languages.yml). When a user views the available templates, those templates that match the same language will feature more prominently.
### Categories
* continuous-integration
* deployment
* testing
* code-quality
* code-review
* dependency-management
* monitoring
* Automation
* utilities
### Variables
These variables can be placed in the starter workflow and will be substituted as detailed below:
*`$default-branch`: will substitute the branch from the repository, for example `main` and `master`
*`$protected-branches`: will substitue any protected branches from the repository.
*`$cron-daily`: will substitute a valid but random time within the day
# xcrun xctrace returns via stderr, not the expected stdout (see https://developer.apple.com/forums/thread/663959)
device=`xcrun xctrace list devices 2>&1 | grep -oE 'iPhone.*?[^\(]+' | head -1 | awk '{$1=$1;print}'`
if [ $scheme = default ]; then scheme=$(cat default); fi
if [ "`ls -A | grep -i \\.xcworkspace\$`" ]; then filetype_parameter="workspace" && file_to_build="`ls -A | grep -i \\.xcworkspace\$`"; else filetype_parameter="project" && file_to_build="`ls -A | grep -i \\.xcodeproj\$`"; fi
# xcrun xctrace returns via stderr, not the expected stdout (see https://developer.apple.com/forums/thread/663959)
device=`xcrun xctrace list devices 2>&1 | grep -oE 'iPhone.*?[^\(]+' | head -1 | awk '{$1=$1;print}'`
if [ $scheme = default ]; then scheme=$(cat default); fi
if [ "`ls -A | grep -i \\.xcworkspace\$`" ]; then filetype_parameter="workspace" && file_to_build="`ls -A | grep -i \\.xcworkspace\$`"; else filetype_parameter="project" && file_to_build="`ls -A | grep -i \\.xcodeproj\$`"; fi
# This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
# This workflow will do a clean install of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions
name:Node.js CI
@@ -16,15 +16,16 @@ jobs:
strategy:
matrix:
node-version:[10.x, 12.x, 14.x, 15.x]
node-version:[12.x, 14.x, 16.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
# This workflow will upload a Python Package using Twine when a release is created
# For more information see: https://help.github.com/en/actions/language-and-framework-guides/using-python-with-github-actions#publishing-to-package-registries
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
GitHub code scanning is a developer-first, GitHub-native approach to easily find security vulnerabilities before they reach production. Before you can configure code scanning for a repository, you must enable code scanning by adding a GitHub Actions workflow to the repository. For more information, see [Enabling Code Scanning for a repository](/github/finding-security-vulnerabilities-and-errors-in-your-code/enabling-code-scanning-for-a-repository).
GitHub code scanning is a developer-first, GitHub-native approach to easily find security vulnerabilities before they reach production. Before you can configure code scanning for a repository, you must enable code scanning by adding a GitHub Actions workflow to the repository. For more information, see [Setting up code scanning for a repository](https://docs.github.com/en/code-security/secure-coding/setting-up-code-scanning-for-a-repository).
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.