starter-workflows
starter-workflows copied to clipboard
Add pages starter workflow for Middleman
Pre-requisites
- [ ] Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.
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:
- [x] Should be contained in a
.ymlfile with the language or platform as its filename, in lower, kebab-cased format (for example,docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET"). - [x] Should use sentence case for the names of workflows and steps (for example, "Run tests").
- [x] Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
- [x] Should include comments in the workflow for any parts that are not obvious or could use clarification.
- [x] Should specify least privileged permissions for
GITHUB_TOKENso that the workflow runs successfully.
For CI workflows, the workflow:
- [ ] Should be preserved under the
cidirectory. - [ ] Should include a matching
ci/properties/*.properties.jsonfile (for example,ci/properties/docker-publish.properties.json). - [ ] Should run on
pushtobranches: [ $default-branch ]andpull_requesttobranches: [ $default-branch ]. - [ ] Packaging workflows should run on
releasewithtypes: [ 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).
For Code Scanning workflows, the workflow:
- [ ] Should be preserved under the
code-scanningdirectory. - [ ] Should include a matching
code-scanning/properties/*.properties.jsonfile (for example,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 theiconsdirectory.
- [ ]
- [ ] Should run on
pushtobranches: [ $default-branch, $protected-branches ]andpull_requesttobranches: [ $default-branch ]. We also recommend ascheduletrigger ofcron: $cron-weekly(for example,codeql.yml).
Some general notes:
- [ ] This workflow must only use actions that are produced by GitHub, in the
actionsorganization, or - [x] 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. 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.
Pre-requisites
- [ ] Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.
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:
- [x] Should be contained in a
.ymlfile with the language or platform as its filename, in lower, kebab-cased format (for example,docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").- [x] Should use sentence case for the names of workflows and steps (for example, "Run tests").
- [x] Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
- [x] Should include comments in the workflow for any parts that are not obvious or could use clarification.
- [x] Should specify least privileged permissions for
GITHUB_TOKENso that the workflow runs successfully.For CI workflows, the workflow:
- [ ] Should be preserved under the
cidirectory.- [ ] Should include a matching
ci/properties/*.properties.jsonfile (for example,ci/properties/docker-publish.properties.json).- [ ] Should run on
pushtobranches: [ $default-branch ]andpull_requesttobranches: [ $default-branch ].- [ ] Packaging workflows should run on
releasewithtypes: [ 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).For Code Scanning workflows, the workflow:
[ ] Should be preserved under the
code-scanningdirectory.[ ] Should include a matching
code-scanning/properties/*.properties.jsonfile (for example,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 theiconsdirectory.[ ] Should run on
pushtobranches: [ $default-branch, $protected-branches ]andpull_requesttobranches: [ $default-branch ]. We also recommend ascheduletrigger ofcron: $cron-weekly(for example,codeql.yml).Some general notes:
- [ ] This workflow must only use actions that are produced by GitHub, in the
actionsorganization, or- [x] 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. 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.
This pull request has become stale and will be closed automatically within a period of time. Sorry about that.
Going to reopen for future consideration. 🤔
@JamesMGreene updated this PR to correspond to your updates in https://github.com/actions/starter-workflows/pull/2244
@JamesMGreene any chance to get this merged? Middleman is one of the most well-known and used (over 5M downloads) static site generators in the Ruby ecosystem (probably the second one, after Jekyll, since Slate is built on top of Middleman):
(source: https://jamstack.org/generators/)
So having an official starter-workflow would be really really appreciated 🙏🏼 Thanks!
This pull request has become stale and will be closed automatically within a period of time. Sorry about that.
@JamesMGreene friendly ping!
I still think Middleman is a relevant static generator in the Ruby community (Top 2 in popularity), so an official starter would be much much appreciated.
Just like in https://github.com/actions/starter-workflows/pull/2255#issuecomment-2198378233, unfortunately, we are not accepting new starter workflows for Pages at the moment.