Some projects observed intermittent build timeouts with Swift.
In case this happens, and our CodeQL-level mitigations do not prevent the problem, we want to avoid using up 6h of the customer's billed macOS Actions minutes (which is the default timeout), so we suggest a reduced timeout of 2h.
This value is chosen to accommodate the total job time (build + CodeQL extraction + CodeQL analysis) we expect for large Swift projects. We may choose to adjust it in future.
CodeQL Swift analysis is best supported on macOS.
In preparation for CodeQL supporting Swift analysis in beta,
adjust the CodeQL starter workflow template to run the `swift` matrix job on `macos-latest`, and all other matrix jobs on
`ubuntu-latest`. This does not affect the matrix itself.
* Add starter workflow for Azure Function App with Gradle
* Mark as preview
* Fix properties for function gradle template
* Add workflow and job level permissions to function gradle template
---------
Co-authored-by: Sampark Sharma <phantsure@github.com>
* Add starter workflow for Azure Web App with Gradle
* Use gradle build instead of assemable and mark template as preview
---------
Co-authored-by: Sampark Sharma <phantsure@github.com>
* Create snyk-security.properties.json
* Create snyk-security.yml
* Update snyk-security.yml
* Fix mispelling
Co-authored-by: Sampark Sharma <phantsure@github.com>
* Apply comments from PR
- Moved documentation link to the top
- Made `|| true` optional
- Added commit SHA for the Snyk GitHub Action
* Remove empty space
Co-authored-by: Sampark Sharma <phantsure@github.com>
* Remove empty space in line end
Co-authored-by: Sampark Sharma <phantsure@github.com>
* Update Categories
* Updated after running pre-commit linting
---------
Co-authored-by: Sampark Sharma <phantsure@github.com>
* Created new workflow for defender for devops
* Create defender-for-devops.properties.json
* fixed pr comments
* fixed linting issues
* fixed linting issues
* removed trailing white space
* changed from preview to v1.6.0
upgrade cosign version
https://github.com/sigstore/cosign/releases/tag/v1.13.1
The current version is out of date and the following error occurs
```
getting signer: getting key from Fulcio: verifying SCT: updating local metadata and targets: error updating to TUF remote mirror: tuf: invalid key
```
Co-authored-by: Sampark Sharma <phantsure@github.com>
* update sw to use kubelogin
* modified set context to use kubelogin
* whitespace issue?
* Reverting bandit file
Co-authored-by: Bishal Prasad <bishal-pdmsft@github.com>
* Added Bandit starter workflow and properties file. Python security scanner, Action by a Hubber, wraps free tool
* Set icon name to one in the icons folder
* Switched to Bandit's own SVG icon
* Added workflow disclaimer
* Fixed author name
Co-authored-by: Sampark Sharma <phantsure@github.com>
Go 1.18 will be at end of life sometime within the coming months (Q1 2023). Go 1.19 will be around until Q3 2023, by which point 1.20 will have been released.
This updates the version of the denoland/setup-deno action used in ci/deno.yml starter workflow to a version that uses node16, to remove the warning about node12 workflows being deprecated.
The version updated to is the latest released version, v1.1.1: https://github.com/denoland/setup-deno/releases/tag/v1.1.1
Scala builds do not automatically get support for the dependency graph. This addition will upload dependency information to the dependency graph so users get Dependabot alerts.
Code Scanning can accept multiple uploads for the same tool and uses the concept of category to keep results separated.
If not provided explicitly, the category is computed based on a few parameters like workflow path and matrix variables. The implicit computation of the category can create confusion if users change their workflow, as we start considering the new analyses as unrelated to existing results.
By making the category explicit in the workflow we hope to make the concept more prominent and reduce accidental changes.
- Fixed a typo in the upload-sarif@v1 action
- Commented out the rules-repository. The template will now default to rules in git://clj-holmes/clj-holmes-rules#main, but the format is preserved.
* commit dummy workflow
* Update nextjs.yml
* renaming
* actually do a node build
* add jekyll build & deploy
* add permissions
* update jekyll to use composite upload action
* update next to use composite upload action
* update icon yml
* change nexjs icon
* Cleanup further the Jekyll template
* add gatsby starter workflow
* fix composite error
* fix updated actions
* Add Hugo
* Apply suggestions from code review
* Inital commit for nuxtjs starter workflow
* Cleanup all templates
* Add baseUrl through an action
* Use `base_url` output for Hugo configuration
* Create static.yml
* Create static.properties.json
* clarify path
* alternative jekyll icon with only tube
* use alternate jekyll icon
* use original xvg with proper viewBox parameters
* Add paper-spa/configure-pages to starter workflows
Replaces paper-spa/setup-pages where appropriate.
* use setup-ruby action instead of our container
* Add starter workflow for GitHub Pages's legacy Jekyll build
Named `jekyll-gh-pages` so that it connotes the familiar "hands off"
build process of the Jekyll build as performed by github pages workers,
without sounding deprecated by using the words "legacy" or "classic".
* Use the static_site_generator input so we can modify the correct config
* Update gatsby.yml
* Update wording on the 'legacy' jekyll workflow
* Fix filename: this should have a json extension
* Fix filename: this should have a .properties.json extension
* Update nextjs.properties.json
* Update static.properties.json
* Fix typo in name of Gatsby
* Remove pull_request triggers
* Update to latest versions of core Actions
* Remove '--if-present' flag from 'npm run build' commands to prevent silent failure
* Perform static HTML export for Next.js
* Add '--no-install' flag to 'npx' usage
* Update Nuxt starter workflow to run 'generate'
* Default to using npm if not using yarn
* Reword 'nuxt generate' step name
* Update pages/gatsby.yml
* Update description of Jekyll starter workflow
* Add configure-pages step to static workflow
* Add configuration step to enable Pages
* Pages: Set `PREFIX_PATHS` env var for Gatsby build
* Update Next.js starter workflow to cache builds
See https://nextjs.org/docs/advanced-features/ci-build-caching#github-actions
* Update NuxtJS starter workflow to cache builds
Basically modeled after the Gatsby starter workflow
* Call out node ssg getting started + setup
* Update nuxt documentation
* Retarget actions referencing `paper-spa` to `actions`
Also point to newly published `v1` tags rather than `main` or `v0`.
Co-authored-by: yimysty <yimysty@github.com>
Co-authored-by: Tommy Byrd <tcbyrd@github.com>
Co-authored-by: Yoann Chaudet <yoannchaudet@github.com>
Co-authored-by: Timothy <tjyung@github.com>
Co-authored-by: Smitha Borkar <12040799+smithaborkar@users.noreply.github.com>
Co-authored-by: James M. Greene <JamesMGreene@github.com>
Whenever a security issue is found the `scan action` fails the build and the step, which causes the workflow to fail before uploading the results to Code Scanning.
This change turns the error into a warning.
* Reworked AKS deployment workflows (#1403)
* rebased to partner_templates
* Renaming workflow
* Updated corresponding properties.json files for the new aks workflows under deployments.
* Updated properties.json titles for aks workflows
* Renamed SECRET_NAME to IMAGE_PULL_SECRET_NAME
* Moved permissions down to the job level
* Updated documentation links
* Updated permission for action to read
* Removing redundant permissions
* write -> read for actions
* Updated descriptions
* Less reference documentation in header
* Added comments to each AKS Starter Workflow step
Co-authored-by: Tommy Barnes <thbarnes@microsoft.com>
* Update AKS workflows to not use imagePullSecrets (#1494)
* removing old method of adding imagePullSecrets
* fixing step casing
* For testing: Dependency review starter workflow
* changed back to image pull secret, added mask, clarified website and pull secret instructions
* made changes to other aks files
* Added back imagepullsecrets param to deploy action, reordered env vars
* changing release version of deploy action
* restructured starter workflows to parallelize secret creation and image building
* renamed to buildImage and removed extra space
* cleaned up some random newlines
* removed extra space
* removing changes from partner branch
* removing changes from partner branch
* through mistake in changing PR, two files lost step for createSecret
Co-authored-by: Tommy Barnes <thomas.jonathan.barnes@gmail.com>
Co-authored-by: Tommy Barnes <thbarnes@microsoft.com>
Co-authored-by: Israel Miller <ismille@microsoft.com>
Co-authored-by: Bishal Prasad <bishal-pdmsft@github.com>
Co-authored-by: Jaiveer Katariya <jaiveerkatariya@Jaiveers-MacBook-Pro.local>
Co-authored-by: Jaiveer Katariya <jaiveerkatariya@rgoldshtein.middleeast.corp.microsoft.com>
Line 51 added the query packs by default but commented.
Lines 62-63: added better instructions
Lines 68-70 added an example which provides better detail
The workflows for Ruby, RubyGem, Jekyll, and similar are all just the name of the language, package, or framework. This name change brings Rails in line with the other starters.
* Update the cosign-install action and default version from 1.4.0 to 1.5.1.
Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>
* Update to 1.7.1 and the latest cosign-installer action.
Signed-off-by: Dan Lorenc <lorenc.d@gmail.com>
Co-authored-by: Bishal Prasad <bishal-pdmsft@github.com>
My previous PR didn't properly handle uppercase usernames (or repository names) when signing container images with `cosign`.
It seems that the `docker buildx --push` doesn't like this either, but it's passed the output of the `docker/metadata-action` which seems to lowercase things.
Fixes: https://github.com/actions/starter-workflows/issues/1293
Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
* Upgrade Rails workflow to true CI
The existing Rails CI example only runs linters, which is not continuous
integration. This change brings the Rails example workflow up to par
with the other web framework CI flows, like Django.
This example is optimized for Rails 7, which does not include NodeJS,
webpack, or yarn by default. No Rails application code changes are
required for this flow to run the tests, and both minitest and rspec are
supported via the `test` rake task.
* add Rails icon
* use env vars, hopefully
* use the full hash for ruby/setup-ruby
* remove PORT since services cannot use it
* stop repeating identical step envs
* resolve env var declaration error
* update setup-ruby to the SHA of v1.92
* use setup-ruby SHA for lint job too
Co-authored-by: Bishal Prasad <bishal-pdmsft@github.com>
Now that cosign 1.4 is out, we can perform keyless signing without panicking on private images (and without `--force` uploading to Rekor).
Signed-off-by: Matt Moore <mattmoor@chainguard.dev>
* Have the starter `docker-publish` action sign digests.
This change installs `sigstore/cosign` using the `cosign-installer` action,
and uses sigstore's "keyless" signing process to sign the resulting image
digest using the action's identity token (see: `id-token: write`).
Signed-off-by: Matt Moore <mattomata@gmail.com>
* Fully qualify the digest, add setup-buildx-action as workaround
* Drop --force, add public repo check
* Use built-in 'private' bit
The `gradle-build-action` provides enhanced execution and caching functionality for Gradle.
This change updates starter workflows to use `v2.0.0` of `gradle-build-action`.
Improvements over invoking Gradle directly include:
- Easier to run the workflow with a particular Gradle version
- More sophisticated and more efficient caching of Gradle User Home between invocations
- Detailed reporting of cache usage and cache configuration options
- Automatic capture of Build Scan links
Co-authored-by: Josh Gross <joshmgross@github.com>
Currently we suggest that folks dual publish to both npm + gpr.
There are a large number of edge cases related to doing this and IMHO it is
not the best practice. Let's make two separate workflows.
* Added Cloudrail according to instructions and existing examples
* Adding Cloudrail according to documentation and examples
* Oops
* Add original Fortify on Demand workflow
* Update Fortify on Demand workflow
* Update Fortify on Demand supported languages
* Add 3rd-party GitHub Actions disclaimer
* Sysdig Secure Inline Scan with SARIF report to starter workflows
* Added some extra comments, Github Actions V2 and changed env vars
* Reviews from PR #1110
* Adding 'Dockerfile' to category list
* Update according to PR review comments
* File renames as requested in PR comments
* Revert "Azure Data Factory CI starter workflow (#1111)" (#1146)
This reverts commit 7f30309cce.
* use env variables for user-set values (#1117)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Apply suggestions from nickfyson's code review
Co-authored-by: Nick Fyson <nickfyson@github.com>
* removing "deployment" templates from sync-ghes (#1127)
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Changed svg logo
* Rename sysdig.svg to sysdig-scan.svg
* Switched svg logo (again) for a better fit
* Rename fortify.json to fortify.properties.json
* Correct character-case of "c" in Cloudrail
* AWS template also used Docker
* trigger on push instead of release (#1157)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Adding MobSF starter workflow
* Adhering to pull request guidelines
* python: update to use python 3.10
Signed-off-by: Rui Chen <rui@chenrui.dev>
* Added new templates for 3 clouds.
* Revert "Added new templates for 3 clouds."
This reverts commit c765d6316f.
* Add ruby and update workflow
* Add workflow for Microsoft C++ Code Analysis
* Updated action to meet guidelines
* quote the version strings
* correct typo in msvc.properties.json
* Update codeql.properties.json
* Update code-scanning/properties/codeql.properties.json
Co-authored-by: Arthur Baars <arthur@semmle.com>
* Update codeql.properties.json
* Update codeql.properties.json
* Update code-scanning/mobsf.yml
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/mobsf.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Fixed typo in workflow that will cause every run to fail
* Update commit SHA
* r: use setup-r@1 and include r@4 for starter (#1169)
* 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>
* elixir: refresh dependencies (#1212)
- setup action got renamed into `setup-beam`
- update elixir and erlang versions
* Updated to main branch version.
Co-authored-by: Yoni Leitersdorf <y@indeni.com>
Co-authored-by: Ruud Senden <ruud.senden@microfocus.com>
Co-authored-by: Ruud Senden <8635138+rsenden@users.noreply.github.com>
Co-authored-by: Manuel Boira Cuevas <manuel.boira@MacBook-Pro.local>
Co-authored-by: manuelbcd <manuel.boira@sysdig.com>
Co-authored-by: Nick Fyson <nickfyson@github.com>
Co-authored-by: Sarah Edwards <skedwards88@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Aparna Ravindra <82894348+aparna-ravindra@users.noreply.github.com>
Co-authored-by: manuelbcd <manuelbcd@gmail.com>
Co-authored-by: Abir Majumdar <abirismyname@github.com>
Co-authored-by: Rui Chen <rui@chenrui.dev>
Co-authored-by: David Verdeguer <daverlo@github.com>
Co-authored-by: Daniel Winsor <danwin@microsoft.com>
Co-authored-by: David Verdeguer <47184891+Daverlo@users.noreply.github.com>
Co-authored-by: Arthur Baars <arthur@semmle.com>
Co-authored-by: Abir Majumdar <83433840+abirismyname@users.noreply.github.com>
Co-authored-by: Marco Gario <marcogario@github.com>
Co-authored-by: Andy McKay <andymckay@github.com>
* Added Cloudrail according to instructions and existing examples
* Adding Cloudrail according to documentation and examples
* Oops
* Add original Fortify on Demand workflow
* Update Fortify on Demand workflow
* Update Fortify on Demand supported languages
* Add 3rd-party GitHub Actions disclaimer
* Sysdig Secure Inline Scan with SARIF report to starter workflows
* Added some extra comments, Github Actions V2 and changed env vars
* Reviews from PR #1110
* Adding 'Dockerfile' to category list
* Update according to PR review comments
* File renames as requested in PR comments
* Revert "Azure Data Factory CI starter workflow (#1111)" (#1146)
This reverts commit 7f30309cce.
* use env variables for user-set values (#1117)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Apply suggestions from nickfyson's code review
Co-authored-by: Nick Fyson <nickfyson@github.com>
* removing "deployment" templates from sync-ghes (#1127)
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Changed svg logo
* Rename sysdig.svg to sysdig-scan.svg
* Switched svg logo (again) for a better fit
* Rename fortify.json to fortify.properties.json
* Correct character-case of "c" in Cloudrail
* AWS template also used Docker
* trigger on push instead of release (#1157)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Adding MobSF starter workflow
* Adhering to pull request guidelines
* python: update to use python 3.10
Signed-off-by: Rui Chen <rui@chenrui.dev>
* Added new templates for 3 clouds.
* Revert "Added new templates for 3 clouds."
This reverts commit c765d6316f.
* Add ruby and update workflow
* Add workflow for Microsoft C++ Code Analysis
* Updated action to meet guidelines
* quote the version strings
* correct typo in msvc.properties.json
* Update codeql.properties.json
* Update code-scanning/properties/codeql.properties.json
Co-authored-by: Arthur Baars <arthur@semmle.com>
* Update codeql.properties.json
* Update codeql.properties.json
* Update code-scanning/mobsf.yml
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/mobsf.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Fixed typo in workflow that will cause every run to fail
* Update commit SHA
* r: use setup-r@1 and include r@4 for starter (#1169)
* 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>
* elixir: refresh dependencies (#1212)
- setup action got renamed into `setup-beam`
- update elixir and erlang versions
Co-authored-by: Yoni Leitersdorf <y@indeni.com>
Co-authored-by: Ruud Senden <ruud.senden@microfocus.com>
Co-authored-by: Ruud Senden <8635138+rsenden@users.noreply.github.com>
Co-authored-by: Manuel Boira Cuevas <manuel.boira@MacBook-Pro.local>
Co-authored-by: manuelbcd <manuel.boira@sysdig.com>
Co-authored-by: Nick Fyson <nickfyson@github.com>
Co-authored-by: Sarah Edwards <skedwards88@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Aparna Ravindra <82894348+aparna-ravindra@users.noreply.github.com>
Co-authored-by: manuelbcd <manuelbcd@gmail.com>
Co-authored-by: Abir Majumdar <abirismyname@github.com>
Co-authored-by: Rui Chen <rui@chenrui.dev>
Co-authored-by: David Verdeguer <daverlo@github.com>
Co-authored-by: Daniel Winsor <danwin@microsoft.com>
Co-authored-by: David Verdeguer <47184891+Daverlo@users.noreply.github.com>
Co-authored-by: Arthur Baars <arthur@semmle.com>
Co-authored-by: Abir Majumdar <83433840+abirismyname@users.noreply.github.com>
Co-authored-by: Marco Gario <marcogario@github.com>
Co-authored-by: Andy McKay <andymckay@github.com>
* Rename "azure.yml" to Node-specific name
* Add templates and properties for other languages
* Add workflow for .NET Core
* Add workflow and properties file for PHP
* Updates from PR review
* Fix EOF
* Use latest versions
* Renamed the file appropriately.
* Put the azure file back.
* Added azure back.
* Revert "Dummy azure templates for showcasing the CD Ordering Behavior (#1194)"
This reverts commit 9ce2a5b56f.
Co-authored-by: Jason Freeberg <jafreebe@microsoft.com>
* 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>
* Rename "azure.yml" to Node-specific name
* Add templates and properties for other languages
* Add workflow for .NET Core
* Add workflow and properties file for PHP
* Updates from PR review
* Fix EOF
* Use latest versions
* Renamed the file appropriately.
* Put the azure file back.
* Added azure back.
Co-authored-by: Jason Freeberg <jafreebe@microsoft.com>
* Rename "azure.yml" to Node-specific name
* Add templates and properties for other languages
* Add workflow for .NET Core
* Add workflow and properties file for PHP
* Updates from PR review
* Fix EOF
* Use latest versions
* Renamed the file appropriately.
Co-authored-by: Jason Freeberg <jafreebe@microsoft.com>
* Added Cloudrail according to instructions and existing examples
* Adding Cloudrail according to documentation and examples
* Oops
* Add original Fortify on Demand workflow
* Update Fortify on Demand workflow
* Update Fortify on Demand supported languages
* Add 3rd-party GitHub Actions disclaimer
* Sysdig Secure Inline Scan with SARIF report to starter workflows
* Added some extra comments, Github Actions V2 and changed env vars
* Reviews from PR #1110
* Adding 'Dockerfile' to category list
* Update according to PR review comments
* File renames as requested in PR comments
* Revert "Azure Data Factory CI starter workflow (#1111)" (#1146)
This reverts commit 7f30309cce.
* use env variables for user-set values (#1117)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Apply suggestions from nickfyson's code review
Co-authored-by: Nick Fyson <nickfyson@github.com>
* removing "deployment" templates from sync-ghes (#1127)
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Changed svg logo
* Rename sysdig.svg to sysdig-scan.svg
* Switched svg logo (again) for a better fit
* Rename fortify.json to fortify.properties.json
* Correct character-case of "c" in Cloudrail
* AWS template also used Docker
* trigger on push instead of release (#1157)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Added new templates for 3 clouds.
* Revert "Added new templates for 3 clouds."
This reverts commit c765d6316f.
* Add workflow for Microsoft C++ Code Analysis
* Updated action to meet guidelines
* correct typo in msvc.properties.json
* Removed the dummy templates used in bug_bash.
Co-authored-by: Yoni Leitersdorf <y@indeni.com>
Co-authored-by: Ruud Senden <ruud.senden@microfocus.com>
Co-authored-by: Ruud Senden <8635138+rsenden@users.noreply.github.com>
Co-authored-by: Manuel Boira Cuevas <manuel.boira@MacBook-Pro.local>
Co-authored-by: manuelbcd <manuel.boira@sysdig.com>
Co-authored-by: Nick Fyson <nickfyson@github.com>
Co-authored-by: Sarah Edwards <skedwards88@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Aparna Ravindra <82894348+aparna-ravindra@users.noreply.github.com>
Co-authored-by: manuelbcd <manuelbcd@gmail.com>
Co-authored-by: Daniel Winsor <danwin@microsoft.com>
* Added Cloudrail according to instructions and existing examples
* Adding Cloudrail according to documentation and examples
* Oops
* Add original Fortify on Demand workflow
* Update Fortify on Demand workflow
* Update Fortify on Demand supported languages
* Add 3rd-party GitHub Actions disclaimer
* Sysdig Secure Inline Scan with SARIF report to starter workflows
* Added some extra comments, Github Actions V2 and changed env vars
* Reviews from PR #1110
* Adding 'Dockerfile' to category list
* Update according to PR review comments
* File renames as requested in PR comments
* Revert "Azure Data Factory CI starter workflow (#1111)" (#1146)
This reverts commit 7f30309cce.
* use env variables for user-set values (#1117)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Apply suggestions from nickfyson's code review
Co-authored-by: Nick Fyson <nickfyson@github.com>
* removing "deployment" templates from sync-ghes (#1127)
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Changed svg logo
* Rename sysdig.svg to sysdig-scan.svg
* Switched svg logo (again) for a better fit
* Rename fortify.json to fortify.properties.json
* Correct character-case of "c" in Cloudrail
* AWS template also used Docker
* trigger on push instead of release (#1157)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Added new templates for 3 clouds.
* Revert "Added new templates for 3 clouds."
This reverts commit c765d6316f.
* Add workflow for Microsoft C++ Code Analysis
* Updated action to meet guidelines
* correct typo in msvc.properties.json
Co-authored-by: Yoni Leitersdorf <y@indeni.com>
Co-authored-by: Ruud Senden <ruud.senden@microfocus.com>
Co-authored-by: Ruud Senden <8635138+rsenden@users.noreply.github.com>
Co-authored-by: Manuel Boira Cuevas <manuel.boira@MacBook-Pro.local>
Co-authored-by: manuelbcd <manuel.boira@sysdig.com>
Co-authored-by: Nick Fyson <nickfyson@github.com>
Co-authored-by: Sarah Edwards <skedwards88@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Aparna Ravindra <82894348+aparna-ravindra@users.noreply.github.com>
Co-authored-by: manuelbcd <manuelbcd@gmail.com>
Co-authored-by: Daniel Winsor <danwin@microsoft.com>
* Added Cloudrail according to instructions and existing examples
* Adding Cloudrail according to documentation and examples
* Oops
* Add original Fortify on Demand workflow
* Update Fortify on Demand workflow
* Update Fortify on Demand supported languages
* Add 3rd-party GitHub Actions disclaimer
* Sysdig Secure Inline Scan with SARIF report to starter workflows
* Added some extra comments, Github Actions V2 and changed env vars
* Reviews from PR #1110
* Adding 'Dockerfile' to category list
* Update according to PR review comments
* File renames as requested in PR comments
* Revert "Azure Data Factory CI starter workflow (#1111)" (#1146)
This reverts commit 7f30309cce.
* use env variables for user-set values (#1117)
Co-authored-by: Josh Gross <joshmgross@github.com>
* Apply suggestions from nickfyson's code review
Co-authored-by: Nick Fyson <nickfyson@github.com>
* removing "deployment" templates from sync-ghes (#1127)
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Update code-scanning/properties/sysdig-scan.properties.json
Co-authored-by: Nick Fyson <nickfyson@github.com>
* Changed svg logo
* Rename sysdig.svg to sysdig-scan.svg
* Switched svg logo (again) for a better fit
* Rename fortify.json to fortify.properties.json
Co-authored-by: Yoni Leitersdorf <y@indeni.com>
Co-authored-by: Ruud Senden <ruud.senden@microfocus.com>
Co-authored-by: Ruud Senden <8635138+rsenden@users.noreply.github.com>
Co-authored-by: Manuel Boira Cuevas <manuel.boira@MacBook-Pro.local>
Co-authored-by: manuelbcd <manuel.boira@sysdig.com>
Co-authored-by: Nick Fyson <nickfyson@github.com>
Co-authored-by: Sarah Edwards <skedwards88@github.com>
Co-authored-by: Josh Gross <joshmgross@github.com>
Co-authored-by: Aparna Ravindra <82894348+aparna-ravindra@users.noreply.github.com>
Co-authored-by: manuelbcd <manuelbcd@gmail.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.
* 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.)
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
-->
- [ ] 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").
## Pre-requisites
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: [ master ]` and `pull_request` to `branches: [ master ]`.
- [ ] 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).
Packaging workflows should run on `release` with `types: [ created ]`.
---
Some general notes:
### **Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.**
- [ ] 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). Workflows using these actions must reference the action 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:
## 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.
- [ ] Should specify least privileged [permissions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token) for `GITHUB_TOKEN` so that the workflow runs successfully.
**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/code-scanning).
- [ ] 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.
- [ ]`creator`: Name of the organization/user 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.
```
- [ ]This workflow must not send data to any 3rd party service except for the purposes of installing dependencies.
- [ ]This workflow must not use 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.
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.
* [automation](automation): solutions for automating workflows.
### Directory structure
* [ci](ci): solutions for Continuous Integration workflows
* [deployments](deployments): solutions for Deployment workflows
* [automation](automation): solutions for automating workflows
* [code-scanning](code-scanning): solutions for [Code Scanning](https://github.com/features/security)
* [pages](pages): solutions for Pages workflows
* [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) and the list of tech stacks available [here](https://github.com/github-starter-workflows/repo-analysis-partner/blob/main/tech_stacks.yml). When a user views the available templates, those templates that match the language and tech stacks will feature more prominently.
### Categories
* continuous-integration
* deployment
* testing
* code-quality
* code-review
* dependency-management
* monitoring
* Automation
* utilities
* Pages
* Hugo
### 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
## How to test templates before publishing
### Disable template for public
The template author adds a `labels` array in the template's `properties.json` file with a label `preview`. This will hide the template from users, unless user uses query parameter `preview=true` in the URL.
Example `properties.json` file:
```json
{
"name":"Node.js",
"description":"Build and test a Node.js project with npm.",
For viewing the templates with `preview` label, provide query parameter `preview=true` to the `new workflow` page URL. Eg. `https://github.com/<owner>/<repo_name>/actions/new?preview=true`.
### Enable template for public
Remove the `labels` array from `properties.json` file to publish the template to public
# This workflow will trigger Datadog Synthetic tests within your Datadog organisation
# For more information on running Synthetic tests within your GitHub workflows see: https://docs.datadoghq.com/synthetics/cicd_integrations/github_actions/
# 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.
# To get started:
# 1. Add your Datadog API (DD_API_KEY) and Application Key (DD_APP_KEY) as secrets to your GitHub repository. For more information, see: https://docs.datadoghq.com/account_management/api-app-keys/.
# 2. Start using the action within your workflow
name:Run Datadog Synthetic tests
on:
push:
branches:[$default-branch ]
pull_request:
branches:[$default-branch ]
jobs:
build:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v2
# Run Synthetic tests within your GitHub workflow.
# For additional configuration options visit the action within the marketplace: https://github.com/marketplace/actions/datadog-synthetics-ci
# This workflow will upload a Python Package using Twine when a release is created
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#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 [Setting up code scanning for a repository](https://docs.github.com/en/code-security/secure-coding/setting-up-code-scanning-for-a-repository).
# Github token of the repository (automatically created by Github)
GITHUB_TOKEN:${{ secrets.GITHUB_TOKEN }}# Needed to get PR information.
# File or directory to run bandit on
# path: # optional, default is .
# Report only issues of a given severity level or higher. Can be LOW, MEDIUM or HIGH. Default is UNDEFINED (everything)
# level: # optional, default is UNDEFINED
# Report only issues of a given confidence level or higher. Can be LOW, MEDIUM or HIGH. Default is UNDEFINED (everything)
# confidence: # optional, default is UNDEFINED
# comma-separated list of paths (glob patterns supported) to exclude from scan (note that these are in addition to the excluded paths provided in the config file) (default: .svn,CVS,.bzr,.hg,.git,__pycache__,.tox,.eggs,*.egg)
# excluded_paths: # optional, default is DEFAULT
# comma-separated list of test IDs to skip
# skips: # optional, default is DEFAULT
# path to a .bandit file that supplies command line arguments
base_uri:https://ast.checkmarx.net # This should be replaced by your base uri for Checkmarx One
cx_client_id:${{ secrets.CX_CLIENT_ID }}# This should be created within your Checkmarx One account : https://checkmarx.com/resource/documents/en/34965-118315-authentication-for-checkmarx-one-cli.html#UUID-a4e31a96-1f36-6293-e95a-97b4b9189060_UUID-4123a2ff-32d0-2287-8dd2-3c36947f675e
cx_client_secret:${{ secrets.CX_CLIENT_SECRET }}# This should be created within your Checkmarx One account : https://checkmarx.com/resource/documents/en/34965-118315-authentication-for-checkmarx-one-cli.html#UUID-a4e31a96-1f36-6293-e95a-97b4b9189060_UUID-4123a2ff-32d0-2287-8dd2-3c36947f675e
cx_tenant:${{ secrets.CX_TENANT }}# This should be replaced by your tenant for Checkmarx One
# 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.
# This is a basic workflow to help you get started with Using Checkmarx CxFlow Action
name:CxFlow
on:
push:
branches:[$default-branch, $protected-branches ]
pull_request:
# The branches below must be a subset of the branches above
branches:[$default-branch ]
schedule:
- cron:$cron-weekly
# A workflow run is made up of one or more jobs that can run sequentially or in parallel - this job is specifically configured to use the Checkmarx CxFlow Action
permissions:
contents:read
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on - Ubuntu is required as Docker is leveraged for the action
permissions:
contents:read# for actions/checkout to fetch code
issues:write# for checkmarx-ts/checkmarx-cxflow-github-action to write feedback to github issues
pull-requests:write# for checkmarx-ts/checkmarx-cxflow-github-action to write feedback to PR
security-events:write# for github/codeql-action/upload-sarif to upload SARIF results
actions:read# only required for a private repository by github/codeql-action/upload-sarif to get the Action run status
# required to fetch internal or private CodeQL packs
packages:read
# only required for workflows in private repositories
actions:read
contents:read
security-events:write
strategy:
fail-fast:false
matrix:
$codeql-languages-matrix
# CodeQL supports the following values keywords for 'language': $supported-codeql-languages
# Use `c-cpp` to analyze code written in C, C++ or both
# Use 'java-kotlin' to analyze code written in Java, Kotlin or both
# Use 'javascript-typescript' to analyze code written in JavaScript, TypeScript or both
# To learn more about changing the languages that are analyzed or customizing the build mode for your analysis,
# see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning.
# If you are analyzing a compiled language, you can modify the 'build-mode' for that language to customize how
# your codebase is analyzed, see https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/codeql-code-scanning-for-compiled-languages
language:[$detected-codeql-languages ]
# CodeQL supports [ $supported-codeql-languages ]
# Use only 'java' to analyze code written in Java, Kotlin or both
# Use only 'javascript' to analyze code written in JavaScript, TypeScript or both
# Learn more about CodeQL language support at https://aka.ms/codeql-docs/language-support
steps:
- name:Checkout repository
uses:actions/checkout@v4
uses:actions/checkout@v3
# Initializes the CodeQL tools for scanning.
- name:Initialize CodeQL
uses:github/codeql-action/init@v3
uses:github/codeql-action/init@v2
with:
languages:${{ matrix.language }}
build-mode:${{ matrix.build-mode }}
# If you wish to specify custom queries, you can do so here or in a config file.
# By default, queries listed here will override any specified in a config file.
# Prefix the list here with "+" to use these queries and those in the config file.
@@ -69,22 +60,23 @@ jobs:
# For more details on CodeQL's query packs, refer to: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs
# queries: security-extended,security-and-quality
# If the analyze step fails for one of the languages you are analyzing with
# "We were unable to automatically build your code", modify the matrix above
# to set the build mode to "manual" for that language. Then modify this step
# to build your code.
# Autobuild attempts to build any compiled languages (C/C++, C#, Go, Java, or Swift).
# If this step fails, then you should remove it and run the build manually (see below)
- name:Autobuild
uses:github/codeql-action/autobuild@v2
# ℹ️ Command-line programs to run using the OS shell.
# 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun
- if:matrix.build-mode == 'manual'
run:|
echo 'If you are using a "manual" build mode for one or more of the' \
'languages you are analyzing, replace this with the commands to build' \
'your code, for example:'
echo ' make bootstrap'
echo ' make release'
exit 1
# If the Autobuild fails above, remove it and uncomment the following three lines.
# modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance.
# 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.
# This workflow will initiate a Contrast Scan on your built artifact, and subsequently upload the results SARIF to Github.
# Because Contrast Scan is designed to run against your deployable artifact, you need to build an artifact that will be passed to the Contrast Scan Action.
# Contrast Scan currently supports Java, JavaScript and .NET artifacts.
# For more information about the Contrast Scan GitHub Action see here: https://github.com/Contrast-Security-OSS/contrastscan-action
# Pre-requisites:
# All Contrast related account secrets should be configured as GitHub secrets to be passed as inputs to the Contrast Scan Action.
# The required secrets are CONTRAST_API_KEY, CONTRAST_ORGANIZATION_ID and CONTRAST_AUTH_HEADER.
on:
push:
branches:[$default-branch, $protected-branches ]
pull_request:
# The branches below must be a subset of the branches above
branches:[$default-branch ]
schedule:
- cron:$cron-weekly
permissions:
contents:read
name:Scan analyze workflow
jobs:
build-and-scan:
permissions:
contents:read# for actions/checkout
security-events:write# for github/codeql-action/upload-sarif
actions:read# only required for a private repository by github/codeql-action/upload-sarif to get the Action run status
runs-on:ubuntu-latest
# check out project
steps:
- uses:actions/checkout@v3
# Since Contrast Scan is designed to run against your deployable artifact, the steps to build your artifact should go here.
# This Action will scan dependency manifest files that change as part of a Pull Request, surfacing known-vulnerable versions of the packages declared or updated in the PR. Once installed, if the workflow run is marked as required, PRs introducing known-vulnerable packages will be blocked from merging.
# Public documentation: https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review#dependency-review-enforcement
# 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.
# EthicalCheck addresses the critical need to continuously security test APIs in development and in production.
# EthicalCheck provides the industry’s only free & automated API security testing service that uncovers security vulnerabilities using OWASP API list.
# Developers relies on EthicalCheck to evaluate every update and release, ensuring that no APIs go to production with exploitable vulnerabilities.
# You develop the application and API, we bring complete and continuous security testing to you, accelerating development.
# Know your API and Applications are secure with EthicalCheck – our free & automated API security testing service.
# How EthicalCheck works?
# EthicalCheck functions in the following simple steps.
# 1. Security Testing.
# Provide your OpenAPI specification or start with a public Postman collection URL.
# EthicalCheck instantly instrospects your API and creates a map of API endpoints for security testing.
# It then automatically creates hundreds of security tests that are non-intrusive to comprehensively and completely test for authentication, authorizations, and OWASP bugs your API. The tests addresses the OWASP API Security categories including OAuth 2.0, JWT, Rate Limit etc.
# 2. Reporting.
# EthicalCheck generates security test report that includes all the tested endpoints, coverage graph, exceptions, and vulnerabilities.
# Vulnerabilities are fully triaged, it contains CVSS score, severity, endpoint information, and OWASP tagging.
# This is a starter workflow to help you get started with EthicalCheck Actions
name:EthicalCheck-Workflow
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the $default-branch branch
# Customize trigger events based on your DevSecOps processes.
push:
branches:[$default-branch, $protected-branches ]
pull_request:
branches:[$default-branch ]
schedule:
- cron:$cron-weekly
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
permissions:
contents:read
jobs:
Trigger_EthicalCheck:
permissions:
security-events:write# for github/codeql-action/upload-sarif to upload SARIF results
actions:read# only required for a private repository by github/codeql-action/upload-sarif to get the Action run status
runs-on:ubuntu-latest
steps:
- name:EthicalCheck Free & Automated API Security Testing Service
# TODO: Customize trigger events based on your DevSecOps processes and typical FoD SAST scan time
on:
workflow_dispatch:
push:
branches:[$default-branch ]
schedule:
- cron:$cron-weekly
jobs:
FoD-SAST-Scan:
# Use the appropriate runner for building your source code.
# TODO: Use a Windows runner for .NET projects that use msbuild. Additional changes to RUN commands will be required to switch to Windows syntax.
runs-on:ubuntu-latest
permissions:
actions:read
contents:read
security-events:write
steps:
# Check out source code
- name:Check Out Source Code
uses:actions/checkout@v3
# Java is required to run the various Fortify utilities.
# When scanning a Java application, please use the appropriate Java version for building your application.
- name:Setup Java
uses:actions/setup-java@v3
with:
java-version:8
distribution:'temurin'
# Prepare source+dependencies for upload. The default example is for a Maven project that uses pom.xml.
# TODO: Update PACKAGE_OPTS based on the ScanCentral Client documentation for your project's included tech stack(s). Helpful hints:
# ScanCentral Client will download dependencies for maven (-bt mvn) and gradle (-bt gradle).
# ScanCentral Client can download dependencies for msbuild projects (-bt msbuild); however, you must convert the workflow to use a Windows runner.
# ScanCentral has additional options that should be set for PHP and Python projects
# For other build tools, add your build commands to download necessary dependencies and prepare according to Fortify on Demand Packaging documentation.
# ScanCentral Client documentation is located at https://www.microfocus.com/documentation/fortify-software-security-center/
# Start Fortify on Demand SAST scan and wait until results complete. For more information on FoDUploader commands, see https://github.com/fod-dev/fod-uploader-java
# TODO: Update ENV variables for your application and create the necessary GitHub Secrets. Helpful hints:
# Credentials and release ID should be obtained from your FoD tenant (either Personal Access Token or API Key can be used).
# Automated Audit preference should be configured for the release's Static Scan Settings in the Fortify on Demand portal.
- name:Download Fortify on Demand Universal CI Tool
# 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.
# Frogbot Scan and Fix does the following:
# Automatically creates pull requests with fixes for vulnerable project dependencies.
# Uses JFrog Xray to scan the project.
# Read more about Frogbot here - https://github.com/jfrog/frogbot#frogbot
# Some projects require creating a frogbot-config.yml file. Read more about it here - https://github.com/jfrog/frogbot/blob/master/docs/frogbot-config.md
name:"Frogbot Scan and Fix"
on:
push:
branches:[$default-branch ]
permissions:
contents:write
pull-requests:write
security-events:write
jobs:
create-fix-pull-requests:
runs-on:ubuntu-latest
steps:
- uses:actions/checkout@v3
# IMPORTANT:
# 1. See the following link for information about the tools that need to be installed for Frogbot to work - https://github.com/jfrog/frogbot/tree/master/docs/templates/github-actions/scan-and-fix
# 2. Some projects require creating a frogbot-config.yml file. Read more about it here - https://github.com/jfrog/frogbot/blob/master/docs/frogbot-config.md
# 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.
# Frogbot Scan Pull Request does the following:
# Automatically scans new pull requests for security vulnerabilities.
# Uses JFrog Xray to scan the project.
# Read more about Frogbot here - https://github.com/jfrog/frogbot#frogbot
# Some projects require creating a frogbot-config.yml file. Read more about it here - https://github.com/jfrog/frogbot/blob/master/docs/frogbot-config.md
name:"Frogbot Scan Pull Request"
on:
pull_request_target:
types:[opened, synchronize ]
permissions:
pull-requests:write
contents:read
jobs:
scan-pull-request:
runs-on:ubuntu-latest
# A pull request needs to be approved, before Frogbot scans it. Any GitHub user who is associated with the
# "frogbot" GitHub environment can approve the pull request to be scanned.
# Read more here (Install Frogbot Using GitHub Actions): https://github.com/jfrog/frogbot/blob/master/docs/install-github.md
environment:frogbot
steps:
- uses:actions/checkout@v2
with:
ref:${{ github.event.pull_request.head.sha }}
# IMPORTANT:
# 1. See the following link for information about the tools that need to be installed for Frogbot to work - https://github.com/jfrog/frogbot/tree/master/docs/templates/github-actions/scan-and-fix
# 2. Some projects require creating a frogbot-config.yml file. Read more about it here - https://github.com/jfrog/frogbot/blob/master/docs/frogbot-config.md
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.