* r: use setup-r@1 and include r@4 for starter
Signed-off-by: Rui Chen <rui@chenrui.dev>
* use sha instead of tag for external action
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
* Azure Data Factory CI starter workflow
* fix: data factory starter categories
* fix: checkout step formatting
* fix: data-factory-export targeting latest version
* feature: latest adf validate and export versions
* feature: Azure Data Factory tech_stack category for CI starter
Co-authored-by: Fernando de Oliveira <5161098+fernandoBRS@users.noreply.github.com>
This commit adds github/super-linter as a starter workflow to execute
several linters based on the user codebase on changed files.
Co-authored-by: Josh Gross <joshmgross@github.com>
- 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>
* 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>
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 workflows.
* [deployments](deployments): solutions for Deployment workflows.
* [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 +22,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 substitute 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/
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 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
# This workflow executes several linters on changed files based on languages used in your code base whenever
# you push a code or open a pull request.
#
# You can adjust the behavior by modifying this file.
# For more information, see:
# https://github.com/github/super-linter
name:Lint Code Base
on:
push:
branches:[$default-branch ]
pull_request:
branches:[$default-branch ]
jobs:
run-lint:
runs-on:ubuntu-latest
steps:
- name:Checkout code
uses:actions/checkout@v2
with:
# Full git history is needed to get a proper list of changed files within `super-linter`
fetch-depth:0
- name:Lint Code Base
uses:github/super-linter@v4
env:
VALIDATE_ALL_CODEBASE:false
DEFAULT_BRANCH:$default-branch
GITHUB_TOKEN:${{ secrets.GITHUB_TOKEN }}
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.