pactflow / actions Goto Github PK

Caveat for existing action

Assumes 'success = true' (you can control this action by depending on an earliler successful test job)

We can control a job running on success or failure, and therefore provide the exit code to one of two jobs

https://github.com/orgs/community/discussions/25809

All the actions specify inputs, e.g. record-deployment/action.yml:

name: "record-deployment"
description: "Record deployment of an application to an environment"
branding:
  icon: "check"
  color: "green"
inputs:
  PACT_BROKER_BASE_URL:
    description: "The url of your pact broker"
    required: true
  PACT_BROKER_TOKEN:
    description: "Your pact broker token"
    required: true
  application_name:
    description: "The name of your application (usually project name)"
    required: true
  version:
    description: "The version of your application (defaults to latest)"
    required: true
runs:
  using: "composite"
  steps:
    - run: ${{ github.action_path }}/recordDeployment.sh
      shell: bash

However, in the bash scripts, the inputs are ignored and the values of environment variables are used.

I never recommend doing this because it's liable to all sorts of race conditions. Can we drop support for this?

Branch not used when publishing, should be sourced in the action and passed through to the publish command

https://github.com/pactflow/actions/blob/main/publish-pact-files/publishPactfiles.sh

as per recommend setup https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts#publish-using-cli-tools

Our Pact checks are taking some time to complete, so we're following the advice in the docs to retry over time. However it doesn't seem like we can set that in the Github Action (only if we swap to CLI).

This is what we expected would work:

    - name: can-i-deploy
      uses: pactflow/actions/[email protected]
      env:
        version: 1.2.3
        to_environment: "dev"
        application_name: app
        retry_while_unknown: 5
        retry_interval: 5

Is this something that should be added here or is there a better way to handle this?

WS-2021-0638 - High Severity Vulnerability

Vulnerable Library - mocha-9.2.2.tgz

simple, flexible, fun test framework

Library home page: https://registry.npmjs.org/mocha/-/mocha-9.2.2.tgz

Path to dependency file: /publish-provider-contract-legacy/package.json

Path to vulnerable library: /publish-provider-contract-legacy/node_modules/mocha/package.json,/can-i-deploy/node_modules/mocha/package.json,/publish-pact-files/node_modules/mocha/package.json,/record-deployment/node_modules/mocha/package.json,/create-version-tag/node_modules/mocha/package.json

Dependency Hierarchy:

• ❌ mocha-9.2.2.tgz (Vulnerable Library)

Found in base branch: main

Vulnerability Details

There is regular Expression Denial of Service (ReDoS) vulnerability in mocha.
It allows cause a denial of service when stripping crafted invalid function definition from strs.

Publish Date: 2021-09-18

URL: WS-2021-0638

CVSS 3 Score Details (7.5)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: None
  • Integrity Impact: None
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://huntr.dev/bounties/1d8a3d95-d199-4129-a6ad-8eafe5e77b9e/

Release Date: 2021-09-18

Fix Resolution: https://github.com/mochajs/mocha/commit/61b4b9209c2c64b32c8d48b1761c3b9384d411ea

• Check this box to open an automated fix PR

Support multiple application_name in can i deploy action.

We have multiple application in the same repo and we want to centralize only one can i deploy.