extenda / actions Goto Github PK

With Cloud Run for GKE we can reference config maps, but the support is not exposed in cloud-run.yaml.

Add support for a breaking change boolean (checkbox) in the release notes integration between conventional commits and JIRA.

If a commit is squashed and merged it contains a (#) reference to the pull request. This should not be included in the JIRA release note.

When creating a PR conventional-version@0 resolves branch-name-short as "merge". Other outputs look fine.
Example:
https://github.com/extenda/hiiretail-price-input-api/runs/1616593094?check_suite_focus=true

The Sonar step fails on OSS SonarQube due to the fact that PR review is not allowed.

SonarQube shouldn't have PR review feedback on by default. It should be an option instead.

When performing a release it seems that the existing release tags are not read correctly. The first ever release works fine and creates a 0.0.1 release and tag in Github. But the following release does not seem to see that this release exists:
No release tags with prefix 'v' exists, use 0.0.0 Conventional commits 'patch' bump from 0.0.0
This will fail the release stage, example: https://github.com/extenda/transaction-repository-pubsub-ingestor/runs/333393273
Not sure if misconfigured workflow or whatever but looks correct 🙂

The current examples for using conventional-version and conventional-release will no longer work. This is caused by a change in actions/checkout@v2 which no longer fetches tags by default. In v2 the default changed to only fetch the last commit.

to get the same behavior with v2 as in v1 it is necessary to use the fetch-depth:0 option

- uses: actions/checkout@v2
  with:
    fetch-depth: 0

Maven settings provided by the file maven-settings.xml should be used as the default settings when calling maven both from actions/maven and using mvn from CLI tools.

Possible solution add action “actions/setup-maven” for setting global maven settings.

When using the following setup:

- name: Create installer packages for vri jobs      
  uses: extenda/actions/rs-create-installerpkg@v0      
  with:        
    builder-type: multiple        
    tool-version: 1.1.0        
    working-dir: .        
    output-dir: installpackages_jobs        
    source-paths: Item\VriPackages        
    package-version: ${{ steps.semver.outputs.version }}      
  env:        
    NEXUS_USERNAME: ${{ env.NEXUS_USERNAME }}        
    NEXUS_PASSWORD: ${{ env.NEXUS_PASSWORD }}

The error appears:
C:\hostedtoolcache\windows\InstallerPackageBuilder.Core.Console\1.1.0\x64\InstallerPackageBuilder.Core.Console.exe multiple -pn "" -wd . -od installpackages_jobs -pv 0.0.1-6 -sp Item\VriPackages
Debug: Starting InstallerPackageBuilder... (InstallerPackageBuilder.Core.Console.Program[0])
'-pn' was not matched. Did you mean '-pv'?
'' was not matched. Did you mean 'wd', or 'od', or 'sp', or 'pv'?
Unrecognized command or argument '-pn'
Unrecognized command or argument ''

If you add multiple sources with multiple input flag eg.
The first will succeed since it only loops over the first source path. While if you try the same over the list of source paths it will not be able to find all packages created.

- name: Create vri jobs installer packages TEST
    uses: extenda/actions/rs-create-installerpkg@v0
    with:
      builder-type: multiple
      tool-version: 1.1.0
      working-dir: .
      output-dir: installpackages_jobs
      source-paths: |
        Source\SuperPosService\VriPackages
      package-version: ${{ steps.semver.outputs.semver }}
      publish-package: true
      publish-root-url: https://repo.extendaretail.com/repository/raw-hosted/RS/
      branch-name-short: ${{ steps.semver.outputs.branch-name-short }}
    env:
      NEXUS_USERNAME: ${{ env.NEXUS_USERNAME }}
      NEXUS_PASSWORD: ${{ env.NEXUS_PASSWORD }}

  - name: Create vri jobs installer packages
    uses: extenda/actions/rs-create-installerpkg@v0
    with:
      builder-type: multiple
      tool-version: 1.1.0
      working-dir: .
      output-dir: installpackages_jobs
      source-paths: |
        Source\SuperPosService\AccountService\VriPackages
        Source\SuperPosService\CommandService\VriPackages
        Source\SuperPosService\DataService\VriPackages
        Source\SuperPosService\InventoryService\VriPackages
        Source\SuperPosService\OperatorService\VriPackages
        Source\SuperPosService\PosClientService\VriPackages
        Source\SuperPosService\ReceiptService\VriPackages
        Source\SuperPosService\TotalsService\VriPackages
        Source\SuperPosService\UtilityService\VriPackages
      package-version: ${{ steps.semver.outputs.semver }}
      publish-package: true
      publish-root-url: https://repo.extendaretail.com/repository/raw-hosted/RS/
      branch-name-short: ${{ steps.semver.outputs.branch-name-short }}
    env:
      NEXUS_USERNAME: ${{ env.NEXUS_USERNAME }}
      NEXUS_PASSWORD: ${{ env.NEXUS_PASSWORD }}

const fullPath = sourcePaths; // path.join(__dirname, sourcePaths); would in the second case use all paths, but not loop correctly over them. Could the solution be to loop over the parent source directories before looping over the directories to get the filenames?

const buildPackage = async (args) => {
  const {
    builderType,
    publishPackage,
    packageVersion,
    outputDir,
    publishUrl,
    branch,
    sourcePaths,
  } = args;

  const buildTool = await downloadBuildTool(args);
  await packageBuilderCommand(buildTool, args);
  if (publishPackage) {
    if (builderType === 'multiple') {
      const fullPath = sourcePaths; // path.join(__dirname, sourcePaths);
      core.info(`Sourcepath fullname: ${fullPath}`);
      const dirs = fs.readdirSync(fullPath)
        .filter((f) => fs.statSync(path.join(fullPath, f)).isDirectory());
      dirs.forEach((dir) => {
        core.info(`DirectoryName: ${dir}`);
        publishPackageCommand({
          packageName: dir,
          packageVersion,
          outputDir,
          publishUrl,
          branch,
        });
      });
    } else {
      publishPackageCommand(args);
    }
  }
  return true;
};

Issue:
our maven build has additional parameters like so:
mvn -B clean install --file pom.xml --settings settings.xml
when using sonar-scanner action build is running only with sonar specific params like so:
mvn -B -V org.sonarsource.scanner.maven:sonar-maven-plugin:3.7.0.1746:sonar -Dsonar.host.url=https://sonar.extenda.io/ -Dsonar.login=*** -Dsonar.projectName=hiiretail-article-streaming
This causes the build to fail not resolving the dependencies.

Fix:
add the ability to specify multiple additional parameters to be able to build the project properly.

The Docker build and push action is not compatible with other actions in this repository that assumes the JSON key is a base64 encoded secret. GCP actions typically expect the key to be base64 encoded and not plain JSON.

The GCP API is also a bit fishy with the _json_key user. It would be more natural to leave out the username.

The action makes incorrect assumptions about tribe and clan being part of the project name. This means we will fail our current auto-discovery of GKE clusters.

Our project names have changed as they can't contain both tribe and clan due to name length restrictions.

It has been noticed that while using ./iam-test-token your user-password iam-test-token-acceptance-password is present in plaintext. Please ensure that secrets are encrypted or not passed as plain text in github workflows.

The SonarCloud Action should fail the build if the quality gate has not been fulfilled. It logs correctly that the quality gate has failed, ##[error]Quality gate is not OK -- exit with error, but it doesn't fail the step/build.

When we release our project on GitHub we want to keep JIRA up to date with fix versions and releases with correct version numbers for issue tracking. This is now a manual job and with conventional commits dictating version numbers it will be harder to manage future releases and fix versions on issues.

The proposal is a new action that automates this in JIRA by accomplishing the following

• Create a new release in JIRA
• Add fix version for all issues mentioned in the commit logs
• Release the version (if releasable - all issues closed)

Once the version is released, this will in turn also trigger automation of release notes and release documentation.

conventional-release action does not seem to add release body when changes were marked by docs and build (maybe something else) types. I understand why "build" changes are not making to the release description but changes marked with "docs" seem like a useful thing to have there.

Please clarify if this is by design or not. If this is by design, any chance to get the compleat list of conventional tags that make it into the release documentation?

Example of release that was produced by merging a PR with "docs" changes - https://github.com/extenda/hiiretail-item-input-api/releases/tag/v2.6.5
PR itself: https://github.com/extenda/hiiretail-item-input-api/pull/105

The release notes from conventional commits should populate associated JIRA ticket(s) when applicable. This allows us to

• Let developers use Git to create release notes
• Review release notes as part of pull requests
• From JIRA - continue further automation pipelines to decorate release notes and publish them to end users

Enhance maven action to use different settings depending on GitHub organization.

In the cloud-deploy action documentation, there is a mistake in the stateful set example
type: stateful-set should be changed to type: StatefulSet

Deploying with the kubernetes action without specifying ports will result in a service resource generated that have to be removed before specifying a port on future deployments.

Solutions for problem:

1. Before deploying the service resource on the cluster, remove the existing one.
2. Make ports required and force the service to open a port internally on the cluster

The JIRA integration can be improved to default to using the repository as component name. We can also make sure that we automatically create the component if it doesn't exist in the project.

The parameters are incorrectly configured for workflows that triggers on push. The action should detect if a PR is opened and include the PR details to perform a PR analysis that includes a status check and a SonarBot PR comment.