* 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.
* Granting execute permission for gradlew
In https://github.com/yashovardhan99/HealersDiary, while testing this action, I noticed `./gradlew build` fails because it does not have execute permissions. Adding the execute permissions using `chmod` fixes this issue.
* fixing line endings
This should fix it
* Renormalizing changes
This workflow will build and push a new container image to Alibaba Cloud Container Reigstry (ACR),
and then will deploy it to Alibaba Cloud Container Service for Kubernetes (ACK), when a release is created.
If the workflow is going to split restore, build, and test into separate
steps, each should use the result of the prior. Build was invoked with
`--no-restore` but test was restoring, building, and then testing.
Noticed that this version of setup-ruby causes problems with the `set-env` deprecation. This just bumps it up to the latest commit on https://github.com/ruby/setup-ruby/
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
Python 3.10 is coming soon, and this will cause problems with the code as currently written. The python versions are written as floats and not strings, which will mean that 3.10 == 3.1, which is going to be very surprising.
it looks like someone tried to use '' to make a ' happen for the possessive tense of users. But that messes up the quoting:
issue-message: 'Message that will be displayed on users'' first issue'
pr-message: 'Message that will be displayed on users'' first pr'
It should be:
issue-message: 'Message that will be displayed on the first issue for that user'
pr-message: 'Message that will be displayed on the first pr for that user'
(this gets rid of the spurious quotes, but also doesn't introduce any grammatical errors)
It was a very bad impression to have a simple script designed to welcome folks be broken by default.
With GitHub Packages everything is ok, but we had a problem with "bearer" in the RubyGems step.
We solved when we removed the bearer in the ruby gem step.
Is it ok?
Repo with our test (https://github.com/rubynetti/amico-db)
D is a statically and strongly typed, multi-paradigm, general-purpose native programming language.
D is fully open-source and maintained by a volunteer community.
For more information, see https://dlang.org
This patch adds a minimal workflow that allows users to compile D projects that use DUB,
the official D package manager and build tool.
The workflow uses the community-maintained `setup-dlang` action,
which can install any version of `dmd` (the reference compiler),
or `ldc` (the LLVM-based, performance oriented compiler,
on any of the three platforms currently supported by Github free runners.
Support for GDC is not yet implemented.
The logo used (d.svg) originates from
https://github.com/dlang/dlang.org/blob/master/images/dlogo_2015.svg
and is available under the BSL-1.0 license
(https://github.com/dlang/dlang.org/blob/master/LICENSE.txt)
Co-Authored-By: Mathias Lang <pro.mathias.lang@gmail.com>
This fixes warning:
Input 'version' has been deprecated with message: The version property will not be supported after October 1, 2019. Use ruby-version instead
When running this action, it will show steps like "Set up job", "Initialize containers" and "Complete job", which are not in Title Case. Nor is "Set up Elixir".
(Some steps like "Post Restore cache" are some sort of half-Title Case, but they seem to be in the minority.)
This patch adds support for deploying an application to IKS
by performing the following steps:
1. Downloading and installing the IBM Cloud CLI,
2. Building locally with Docker,
3. Pushing to ICR (IBM Container Registry), and
4. Deploying with kubectl to IKS
Co-authored-by: JJ Asghar <jjasghar@gmail.com>
Signed-off-by: Steve Martinelli <s.martinelli@gmail.com>
This workflow assumes an App Service web app has already been created and that a user knows how to obtain the desired input values. This cannot be assumed. Therefore I have included references to the relevant documentation.
We should have consistent line endings in our repository; now that we
have a .gitattributes file, update the repository contents to match
expectations.
The setup-node action will default the scope to the correct user (the repo owner), so we do not need to explicitly include it in the workflow. Removing it ensures that the starter template is easier for people to use; now there are no changes necessary to get started. https://github.com/actions/setup-node/blob/master/src/authutil.ts#L26
https://github.com/Licsber/opencv-docker/runs/514244582?check_suite_focus=true
Push image:
Error parsing reference: "docker.pkg.github.com/Licsber/opencv-docker/opencv:latest" is not a valid repository/tag: invalid reference format: repository name must be lowercase
My username contains uppercase characters, this make push failed.
So fix the bug by change all uppercase in IMAGE_ID to lowercase.
2.2 is no longer supported, so moving to latest SDK released for .NET core which supports and encourages LTS runtime version as well as down-level building.
Thank you for sending in this pull request. Please make sure you take a look at the [contributing file](https://github.com/actions/starter-workflows/blob/master/CONTRIBUTING.md). Here's a few things for you to consider in this pull request:
<!--
IMPORTANT:
- [ ] Include a good description of the workflow.
- [ ] Links to the language or tool will be nice (unless its really obvious)
This repository contains configuration for what users see when they click on the `Actions` tab and the setup page for Code Scanning.
In the workflow and properties files:
It is not:
* A playground to try out scripts
* A place for you to create a workflow for your repository
-->
- [ ] Includes a matching `ci/properties/*.properties.json` file.
- [ ] Use title 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 `push`.
- [ ] Packaging workflows should run on `release` with `types: [created]`.
## Pre-requisites
Some general notes:
- [ ] 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).
- [ ] Does not use an Action that isn't in the `actions` organization.
- [ ] Does not send data to any 3rd party service except for the purposes of installing dependencies.
- [ ] Does not use a paid service or product.
---
### **Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.**
---
## Tasks
**For _all_ workflows, the workflow:**
- [ ] 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 ]`.
- [ ] 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)).
**For _Code Scanning_ workflows, the workflow:**
- [ ] 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
# separate terms of service, privacy policy, and support
# documentation.
```
- [ ] 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.
Thank you 🙇 for this request. This request has been classified as a feature by the maintainers.
We take all the requests for features seriously and have passed this on to the internal teams for their consideration.
Because any feature requires further maintenance and support in the long term by this team, we would like to exercise caution into adding new features. If this feature is something that can be implemented independently, please consider forking this repository and adding the feature.
Sorry, but we'd like to keep issues related to code in this repository. Thank you 🙇
If you have questions about writing workflows or action files, 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/articles/about-github-actions#contacting-support)
Hi there 👋 We are excited that you want to contribute a new workflow to this repo. By doing this you are helping people get up and running with GitHub Actions and that's cool 😎.
Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](https://github.com/actions/starter-workflows/blob/master/LICENSE).
Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](https://github.com/actions/starter-workflows/blob/main/LICENSE).
Please note that this project is released with a [Contributor Code of Conduct](
https://github.com/actions/.github/blob/master/CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
https://github.com/actions/.github/blob/main/CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms.
**At this time we are only accepting new starter workflows for Code Scanning**
### Previous guidelines for new starter workflows.
Before merging a new workflow, the following requirements need to be met:
- Should be as simple as is needed for the service.
- 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.
-Should not send data to any 3rd party service except for the purposes of installing dependencies.
-Cannot use an Action that isn't in the `actions` organization.
-Cannot be to a paid service or product.
-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 require that Actions outside of the `actions` organization be pinned to a specific SHA.
These are the workflow files for helping people get started with GitHub Actions. They're presented whenever you start to create a new GitHub Actions workflow.
**If you want to get started with GitHub Actions, you can use these starter workflows by clicking the "Actions" tab in the repository where you want to create a workflow.**
These are the workflow files for helping people get started with GitHub Actions.
### Directory structure
**Directory structure:**
* [ci](ci): solutions for Continuous Integration
* [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
Each workflow must be written in YAML and have a `.yml` extension. They also need a corresponding `.properties.json` file that contains extra metadata about the workflow (this is displayed in the GitHub.com UI).
For example: `ci/python-django.yml` and `ci/python-django.properties.json`.
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
# This workflow will build a docker container, publish it to Google Container Registry, and deploy it to GKE.
#
# To configure this workflow:
#
# 1. Ensure that your repository contains the necessary configuration for your Google Kubernetes Engine cluster, including deployment.yml, kustomization.yml, service.yml, etc.
#
# 2. Set up secrets in your workspace: GKE_PROJECT with the name of the project, GKE_EMAIL with the service account email, GKE_KEY with the Base64 encoded JSON service account key (https://github.com/GoogleCloudPlatform/github-actions/tree/docs/service-account-key/setup-gcloud#inputs).
#
# 3. Change the values for the GKE_ZONE, GKE_CLUSTER, IMAGE, REGISTRY_HOSTNAME and DEPLOYMENT_NAME environment variables (below).
name:Build and Deploy to GKE
on:
push:
branches:
- master
# Environment variables available to all jobs and steps in this workflow
# 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, 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
on:
push:
branches:[$default-branch ]
pull_request:
branches:[$default-branch ]
jobs:
build:
runs-on:ubuntu-latest
strategy:
matrix:
node-version:[12.x, 14.x, 16.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
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.