npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

dz-cicd

v3.0.1

Published

A Node.js package that provides ablity to tackle both package/non-package based Salesforce CICD

Downloads

1,970

Readme

dz-cicd

A Node.js package that provides ablity to tackle both package/non-package based Salesforce CICD

Installation

Simply add your repository with workspace prefix to cicd config json (build/cicd/cicd.config.json), it would make push install/upgrade to your target repository once it's added

 "dependentRepos": "{workspace}/{repo_slug_1},{workspace}/{repo_slug_2}"

Note: only necessary local setting files will be added to the target repositories

Scratch org build tool

A scratch org build tool that can be used remotely and locally - bso (build scratch org)

Prerequisite: install latest sfdx https://developer.salesforce.com/tools/sfdxcli
install latest NodeJS https://nodejs.org/en/download/

Using npm:

a) creating scratch org for development: npm run bso -- Scratch_Org_Alias

b) creating scratch org for ci process: npm run bso -- --ci

Using yarn:

a) creating scratch org for development: yarn bso Scratch_Org_Alias

b) creating scratch org for ci process: yarn bso --ci

- Note: if scratch org build failed halfway(after a scratch org is created in production), remember to delete it in production as a salesforce record and run the tool again or fix it properly like manaully installing dependencies, update cicd config with new ci org username, etc

Cicd Config - org-based repository

"prodLoginURL": "https://test.my.salesforce.com",
+ stagingUser/qaUser will auto-append .staging and .qa respectively if left blank
"prodUser": "",
"prodBranch": "master",
"stagingUser": "",
+ only specify this if a different user other than prodUser is needed
"stagingBranch": "staging",
"stagingSandbox": "staging",
"qaUser": "",
+ only specify this if a different user other than prodUser is needed
"qaBranch": "qa",
"qaSandbox": "qa",
"devBranchPrefixes": "feature,bugfix,hotfix",
"bitbucketUserEmail": "",
"bitbucketUsername": "",
"bitbucketApiUrl": "https://api.bitbucket.org/",
"jiraUserName": "",
"jiraUrl": "https://test.atlassian.net/",
"teamWebhookUrl": "",
"runPostDeployApex": false,
"runLwcTests": false,
"runApexTests": true,
"testLevel": "RunSpecifiedTests",
"excludedApexTests": "fflib_",
"flowsToCleanup": "Account_After_Save,Case_After_Save",
+ clean-up flows which has versions marked as obsolete, alternatively use value "All" to run it against for all flows in the org
"preDestructiveChanges": "labels/CustomLabels.labels-meta.xml,pages/Start_Chatting_new.page",
+ this feature does NOT support metadata type of flow
"skipMetadata": "workflows/Case.workflow-meta.xml,labels/CustomLabels.labels-meta.xml",
+ it removes the metadata listed from validation/deployment (but stays in the repository)
"renameMetadata": "workflows/NEW_Case.workflow-meta.xml,labels/NEW_CustomLabels.labels-meta.xml",
+ renaming adds more complexity, so must specify the newly named metatdata otherwise cicd would consider it as delete&add
"sprintModel": true,
+ if no particular reason just stick with sprint model=true
"debugXmlManifests": false,
"debugCliCommand": false,
"debugCliCommandResult": false

Cicd Config - package-based repository

"prodLoginURL": "https://test.my.salesforce.com",
"prodUser": "",
"prodBranch": "master",
"prodDeployPackageVersion": "Last Validated",
+ either use value 'Last Validated' or package version id(04tf4000004Mgxxxxx)
"stagingUser": "",
"stagingBranch": "staging",
"stagingSandbox": "staging",
"qaUser": "",
"qaBranch": "qa",
"qaSandbox": "qa",
"qaValidatePackage": true,
"bitbucketUserEmail": "",
"bitbucketUsername": "",
"bitbucketApiUrl": "https://api.bitbucket.org/",
"jiraUserName": "",
"jiraUrl": "https://test.atlassian.net/",
"teamWebhookUrl": "",
"packageName": "",
+ just leave it as blank cicd package push install/upgrade will populate this field automatically
"skipAncestorCheck": true,
"dependentPackageRepos": "{workspace}/{repo_slug_1},{workspace}/{repo_slug_2}",
+ specify packages which are dependent on it so cicd would auto-process other package repositories for post-steps
"runLwcTests": false,
"runApexTests": true,
"testLevel": "",
+ if left blank, it would be defaulted to RunLocalTests
"testApexFolderPath": "force-app/main/default/classes/Test Apex/",
+ specify folder path so it would just run test classes within it whenever tests run is needed
"runApexTestsPostInstall": true,
"excludedApexTestsPostInstall": "fflib_",
"runPostDeployApex": false,
"includeApexDebug": false,
+ if set to true when build a new package it will uncomment all the 'System.debug' Statements in the code, once new package is created the field will be reverted to false automatically
"bumpVersionNumber": "minor",
+ specify which package version number for version bump when running post-steps after production CD is done
"isVersionBumped": false,
+ in general this field would be managed automatically during cicd to indicate whether package version has been bumped
"prepData": false,
+ this is used to prepare sample data for dev scratch org, sample data normally are pre-created in data folder under project root
"debugCliCommand": false,
"debugCliCommandResult": false

notes

  • only repo/package based local settings are in repo but all cicd processing related code is removed locally, when running a build it will be freshly pulled up via npm package

  • prodUser now is a dedicated automation user, staging and qa user will be derived from it with .staging and .qa suffix

  • build related detail/debug info is more granular with new params introduced - "debugCliCommand": true, "debugCliCommandResult": true

  • templating/SF repo setup - qa and staging branch will be auto-created if missing when installing cicd pacakge, also based upon repo type(package/org based) and SF metadata folders/files live in a repo, it will add common setup files/tools for it, e.g. pre-commit hook,prettier/formatter,linter,lwc test framework,scratch org builder, etc

  • cicd_manual_qa for creating new package now is NOT a separate pipeline option anymore, all branches now follow the same code entry and branch name/option is all that matters, based upon different branch name it will dynamically invoke corresponding cicd environment for the cicd process