heroku/salesforce-buildpack

Heroku Buildpack for Salesforce

This project is the old Ruby CLI for Heroku. This is the current CLI.

salesforce-buildpack's Issues

Duplicate createPackage2Version() function in /lib/sfdx.sh

The function createPackage2Version() is repeated in the /lib/sfdx.sh script:

# <package_name>
createPackage2Version() {

  packageName="$1"
  
}

# <package_name>
createPackage2Version() {

  packageName="$1"
  
}

Review apps no longer depend on parent

With the new Review apps on Heroku, this buildpack no longer seems to work since there is no longer a parent relation with Review apps. You'll need to set the config values on the pipeline manually

Support JWT Auth

JWT Auth is recommend for server to server auth.

sfdx force:org:display --verbose --json does not include an sfdxAuthUrl when authorized via JWT

creating scratch org (Review Apps) set username as default for postdeploy script

I am working on some NPSP projects. I want to be able to spin up a review app and have the postdeploy install the necessary npsp packages. I have a .sh script that I use for installing on my created scratch orgs.

However when I use this script as a postdeploy script I get errors:

Updating PATH to include Salesforce CLI ...
Installing Package 1: Contacts & Organizations...
ERROR: No org configuration found

Try this:
Run the "sfdx force:auth" commands with --setdefaultusername to connect to an org and set it as your default org.
Run "force:org:create" with --setdefaultusername to create a scratch org and set it as your default org.
Run "sfdx force:config:set defaultusername=" to set your default username.
�[?25hInstallation failed.

the command being run is:
sfdx force:package:install -i 04t80000001AWvwAAG -w 100

Is this something that would be possible?

Thanks!

Don

Support running apex tests without Heroku CI

I propose that the run-apex-tests property parsed from sfdx.yml indicate whether the release phase explicitly runs apex tests or not rather than relying on Heroku CI enabled.

Currently, to get tests to run, then users must enable Heroku CI. However, Heroku CI is a paid add-on and creates its own scratch org separate from the scratch org used by Review Apps.

This feature change would cause the release script to explicitly run the apex tests after deploying code (package.xml or packages).

Benefit is that developers can get their builds to run their tests without paying for the Heroku CI add-on, but have the option to enable Heroku CI for its additional features of (a) GitHub Statuses and (b) control gate on automatic deployments and (c) testing for every push.

The biggest win here would be with Review Apps, and possible this feature might be scoped to Review stage entirely and leave Heroku CI for all other forms of test running.

Review App Creation - Error in Running Scripts and Scaling Dynos step

I have been trying to use the sample app @ https://github.com/wadewegner/salesforce-dx-pipeline-sample and receive errors at the 'Run Scripts and scale dynos' step of the review app creation. The build and deployment goes well but the app isn't accessible because of the error.

I have updated my Heroku and Salesforce CLIs as well.

My forked repo with the updated setup.sh and related files is @ https://github.com/abychat/salesforce-dx-pipeline-sample

I tried this on another app and got the same result.

Timed out running buildpack salesforce-buildpack

Hello,

it seems that i am reaching a timeout because of installing many managed package on the scratch org initialisation.

Indeed during the build i receive a "Timed out running buildpack salesforce-buildpack".

Do you know if it is possible to increase the threshold ?

Thank you

Automatically Set Buildpack in Heroku

When a project is detected that has a sfdx-project.json file it should automatically use this buildpack. This requires changes on heroku's side that are not part of this buildpack.

Time out when creating review app

Hello,

On my customer context, we need to install a series of managed package in our scratch org before deploying our project.

During initialisation of scratch org review, we are blocked by a timeout which prevent us from installing the last two managed package.

Is there a way to increase this time out when building scratch org review ?

Thank you

TypeError: force.sourceConvertApi is not a constructor

I'm currently using this buildpack to deploy my lightning app to a given environment. I'm currently running into an issue in the deploy call.
Here's the stack trace: with debug info

[DEBUG] Deploy options: {"polltimeout":600000,"pollinterval":10000,"deploydir":".cache/mdapi-source","targetusername":"[email protected]","wait":600000,"verbose":true,"json":true,"loglevel":"debug"} ! TypeError: force.sourceConvertApi is not a constructor at deploySource (/app/.salesforce/force.js:201:30) at release (/app/.salesforce/force.js:262:27) at Promise.resolve.then (/app/.salesforce/force.js:325:28) at tryCatcher (/app/.local/heroku/plugins/node_modules/bluebird/js/release/util.js:16:23) at Promise._settlePromiseFromHandler (/app/.local/heroku/plugins/node_modules/bluebird/js/release/promise.js:510:31) at Promise._settlePromise (/app/.local/heroku/plugins/node_modules/bluebird/js/release/promise.js:567:18) at Promise._settlePromiseCtx (/app/.local/heroku/plugins/node_modules/bluebird/js/release/promise.js:604:10) at Async._drainQueue (/app/.local/heroku/plugins/node_modules/bluebird/js/release/async.js:143:12) at Async._drainQueues (/app/.local/heroku/plugins/node_modules/bluebird/js/release/async.js:148:10) at Immediate.Async.drainQueues (/app/.local/heroku/plugins/node_modules/bluebird/js/release/async.js:17:14) at runCallback (timers.js:574:20) at tryOnImmediate (timers.js:554:5) at processImmediate [as _immediateCallback] (timers.js:533:5)

Any help would be much appreciated.

Deploy script should do structured logging rather than free multi-line text

Currently the .salesforce/deploy is doing free text logging style similar to what is seen in build scripts. However, it should be a structured app-style logging.

Package installation requires respond to prompt and fails

My package installation fails since it needed access to remote sites granted which it prompts for. I updated the code and created a pull request for adding --noprompt to the package installation command.

Push rejected, failed to compile salesforce-buildpack app.

Howdy team,

I am writing a blog post so ISVs can better adopt the buildpack, but just ran into an issue:

When I merge a pull request I am getting the following error:

DEBUG] CMD: sfdx force:package2:list --json | jq '.result[] | select((.Name) == "mypipelinedemo")' | jq -r .Id ▸ force:package2:list is not a sfdx command. ▸ Perhaps you meant force:package:list ▸ Run sfdx help force for a list of available topics. ! Push rejected, failed to compile salesforce-buildpack app. ! Push failed

Shouldn't the command be: force:package:list, not force:package2:list?

Remove need for app.json to define test environment

Currently, developers add the app.json file to their project to hook into Heroku Flow. However, the test scripts property reveals scripts and knowledge specific to the buildpack itself:

./vendor/sfdx/release.sh ci-$HEROKU_TEST_RUN_COMMIT_VERSION

This feature request is for the buildpack to provide a default test-compile and test scripts (as mentioned here) that (a) can be called by both Heroku CI and #33 and (b) allow the removal of test scripts from app.json unless a developer needs to tweak the behavior.

Set "Open App" url in heroku to the Salesforce Org's URL

After the build is completed the dashboard's open app url should be pointed to the saleforce org. This requires changes on heroku.

Auth to DH for package-create.sh calls

Currently the buildpack only auths to DevHub when the buildpack calls force:package2:version:create. Custom creation (via package-create.sh) also needs DevHub auth.

See PR: #19

Thoughts on moving sfdx.yml into app.json "env" property?

/lib/release.sh parses the sfdx.yml file to expose properties to the environment that indicate things like whether apex tests should be run or not.

I would like your thoughts on the idea if sfdx.yml were replaced by storing the properties in the app.json's env section?

I think the benefits would be:

• One less file the developer needs to maintain in their project to adopt Heroku Pipelines
• Consistent exposure of environment variables through Heroku's app.json mechanism
• Would not need to maintain the parse_yaml function

If you agree this makes sense, I'm happy to work on a pull request.

Thanks

Remove need for app.json to specify pr-predestroy script

Just as Heroku CI will automatically look for bin/test-compile and bin/test scripts, if it's possible for Heroku during review app destroy step to look for something like bin/pr-predestroy script then that would allow the buildpack to provide a default and developers not to have this knowledge in their app.json unless they wanted to customize the behavior.

Currently, developers are adding the below snippet to their app.json, which relies on underlying knowledge of what artifacts this buildpack generates.

Moving package to --setasreleased

Packages can't be installed on production without having a version:update with the --setareleased option. Currently the buildpack does the same package installation Dev, Staging and Prod. In a test scenario not using prod Orgs (Sandboxes) this works fine. However using a non-Sandbox as Prod Org doesn't install the package with the message: "Unable to install beta package". So Pipeline isn't doing fully automated deployment.
Will test with an additional step if STAGE = PROD to release the package, and create a pull request if successful.