End Of Support

End Of Support:

For the new workflow ref:

• NodeJS-CI
• Pulse Dependency Analytics
• Pulse SAST Analytics

As an extended support this workflow is made to continue to work, but again this workflow calls the new above reusable workflows

What's Changed

• feat!: End of support by @mohankumar-studiographene in #31

Full Changelog: v5.3.0...v6.0.0

Enhancement: Container Scan made as reusable workflow

What:

Enhancement:

• Container Scan made as reusable workflow

Fix

• Pr agent inputs names incorrect

Why:

info:

What's Changed

What's Changed

• Feat(container scan): reusable by @mohankumar-studiographene in #30

Full Changelog: v5.2.0...v5.3.0

Enhancement: PR agent made as reusable workflow

What:

Enhancement:

• PR agent made as reusable workflow
• checkout action upgrade -> v4

Why:

info:

What's Changed

• chore(pr_agent): Job made to use reusable workflow by @mohankumar-studiographene in #28

Full Changelog: v5.1.0...v5.2.0

Feature: Semgrep and OSV reports updated for failed and successful scans

What:

Feature :

• Semgrep and OSV reports now use output files to publish in PR
• Both reports have configured with success or fail messages based on the status of the respective scan.

Why:
info:

What's Changed

• Feature/updated reports by @aakashdeshpandesg in #27

Full Changelog: v5.0.0...v5.1.0

Features: Moved jobs to steps, OSV, SAST reports update

What:

Features :

• Jobs divided into Security Scans, Technology Based Scans, and Codium Scan
• Moved Jobs to Steps
• OSV Dependency Scan report to publish in PR.
• SAST Scan fails the job in there are findings.
• Codium pr_agent scan runs on issue comment.

Why:
info:

Feature: Trivy container scan

What:

Feature

Trivy container scan

No changes needed from users side on workflow to use this new feature. Container scan will run in the Docker build Job.

Why:

info:

What's Changed

Full Changelog: v4.1.1...v4.2.0

Fix: input `project_name` backward compatibility added

What:

Fix

input project_name added for backwards compatibility.

Why:

info:

Users no need to pass input project_name to the workflow.

Feature: Pulse dependency, SAST analytics workflows

What:

Feature

Pulse dependency, SAST analytics workflows added.

Ref to README for help using the workflow.

Why:

info:

v4.0.2: Additional optional steps to pass commands in each job before or after its execution

What:
Introduced Additional Optional Steps in v4.0.2: Now, users have the flexibility to include custom commands before or after the execution of each job.

Why:
To cater to project-specific needs, this update allows the injection of supplementary commands in jobs, either before or after their execution.

Info:
These extra commands can be specified through dedicated arguments for each job, depending on whether the command should be executed before or after the job. Here are examples of supported arguments for specific jobs:

Danger Job:
danger_before_step_command: string (default: "")
danger_after_step_command: string (default: "")

Semgrep Job:
semgrep_before_step_command: string (default: "")
semgrep_after_step_command: string (default: "")

SBOM Job:
sbom_before_step_command: string (default: "")
sbom_after_step_command: string (default: "")

OSv Job:
osv_before_step_command: string (default: "")
osv_after_step_command: string (default: "")

License Scan Job:
licensescan_before_step_command: string (default: "")
licensescan_after_step_command: string (default: "")

Gitleaks Job:
gitleaks_before_step_command: string (default: "")
gitleaks_after_step_command: string (default: "")

PR Agent Job:
pr_agent_before_step_command: string (default: "")
pr_agent_after_step_command: string (default: "")

Caching Job:
caching_before_step_command: string (default: "")
caching_after_step_command: string (default: "")

Docker Job:
docker_before_step_command: string (default: "")
docker_after_step_command: string (default: "")

Lint Job:
lint_before_step_command: string (default: "")
lint_after_step_command: string (default: "")

Build Job:
build_before_step_command: string (default: "")
build_after_step_command: string (default: "")

How to Use in Workflow:
In the workflow file, any of the above-mentioned arguments can be utilised based on the job's requirements. Commands can be passed using the specified arguments.
For example, to pass a command in the build job before its actual execution:

    name: studiographene-ci
    
    on:
      pull_request: {}
      workflow_dispatch:
    
    jobs:
      call-workflow:
        uses: studiographene/nodejs-ci/.github/workflows/ci.yml@master
        with:
          project_name: microservice-boilerplate
          build_before_step_command: command to pass
        secrets: inherit
        permissions: write-all

Fix: CI utility directory ref

What:

Fix:

CI utility directory ref

Why:

info: