Linkedin Pages update Verified

[mameenk24]

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: [partner.github.com/apply](https://partner.github.com/apply?partnershipType=Technology+Partner beIN Media Group ).

---

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 format (for example, 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 for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, 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).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (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 the icons directory.
• 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).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, 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. 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.

[mameenk24]

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: [partner.github.com/apply](https://partner.github.com/apply?partnershipType=Technology+Partner beIN Media Group ).

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 format (for example, 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 for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, 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).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.

• Should include a matching code-scanning/properties/*.properties.json file (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 the icons directory.

• 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).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, 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. 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.

[email protected].
[email protected]

[mameenk24]

[email protected]

[mameenk24]

[email protected]

[wandyflowxx]

Prerrequisitos

• Antes de enviar un nuevo flujo de trabajo, solicite unirse al Programa de socios tecnológicos de GitHub: [partner.github.com/apply]( https://partner.github.com/apply?partnershipType=Technology+Partner beIN Media Group ).

Tenga en cuenta que, por el momento, solo aceptamos nuevos flujos de trabajo iniciales para el escaneo de código. Se admiten actualizaciones de los flujos de trabajo iniciales existentes.

Tareas

Para todos los flujos de trabajo, el flujo de trabajo:

• Debe estar contenido en un .ymlarchivo cuyo nombre de archivo sea el idioma o la plataforma, en minúsculas ( por ejemplo, docker-image.yml). Los caracteres especiales deben eliminarse o reemplazarse por palabras según corresponda (por ejemplo, ".net" en lugar de ".NET").
• Se deben utilizar mayúsculas y minúsculas para los nombres de los flujos de trabajo y pasos (por ejemplo, "Ejecutar pruebas").
• Debe nombrarse únicamente con el nombre del lenguaje o plataforma (por ejemplo, "Go", no "Go CI" o "Go Build").
• Se deben incluir comentarios en el flujo de trabajo para cualquier parte que no sea obvia o que pueda necesitar una aclaración.
• Se deben especificar los permisos con menos privilegios para GITHUB_TOKENque el flujo de trabajo se ejecute correctamente.

Para los flujos de trabajo de CI , el flujo de trabajo:

• Debe conservarse en el cidirectorio .
• Debe incluir un ci/properties/*.properties.jsonarchivo coincidente (por ejemplo, ci/properties/docker-publish.properties.json).
• Debería continuar pushhacia branches: [ $default-branch ]y pull_requesthacia branches: [ $default-branch ].
• Los flujos de trabajo de empaquetado deben ejecutarse releasecon types: [ created ].
• Los flujos de trabajo de publicación deben tener un nombre de archivo que sea el nombre del idioma o la plataforma, en minúsculas, seguido de "-publish" (por ejemplo, docker-publish.yml).

Para los flujos de trabajo de escaneo de código , el flujo de trabajo:

• Debe conservarse en el code-scanningdirectorio .

• Debe incluir un code-scanning/properties/*.properties.jsonarchivo coincidente (por ejemplo, code-scanning/properties/codeql.properties.json), con propiedades configuradas de la siguiente manera:

  • name:Nombre de la integración de escaneo de código.
  • creator:Nombre de la organización/usuario que produce la integración de escaneo de código.
  • description:Breve descripción de la integración de escaneo de código.
  • categories:Matriz de idiomas admitidos por la integración de escaneo de código.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.

• 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).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, 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. 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.

[email protected]

[wandyflowxx]

El vie, 17 oct 2025, 6:00, MOHAMMED AMEEN KADIYARAKAM < ***@***.***> escribió:

…

*mameenk24* left a comment (actions/starter-workflows#3085) <#3085 (comment)> ***@***.*** — Reply to this email directly, view it on GitHub <#3085 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BWPAQVQDB764HKIEWVKGSPD3YBSUPAVCNFSM6AAAAACJN6DI7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMJTG42DQNRZGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mameenk24]

`Ï1

[mameenk24]

beinmediagroup.com/mohammed-ameen-k44-beinbein.com