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

[douglascayers]

/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

[mars]

Ideally any new declarative build functionality will be configured in the vastly improved, next gen, developer preview heroku.yml.

It’s not clear to me exactly how this is used. Would you reach out to me internally to talk through this sfdx-Heroku dependency?

[wadewegner]

sfdx.yml was defined independent of this buildpack and is used by several other deployment tools. I'm not opposed to getting rid of it, but I want to be mindful of keeping things consistent with other tools.

@mars It shows heroku.yml is still in developer preview. It'd be good to understand limitations and if it's a complete replacement for app.json (and what that means for buildpacks, etc).

[wadewegner]

Looks like you still need the app.json for review apps. If we decide to switch, I'd prefer to stick with app.json until sfdx.yml is a complete replacement.

Also it doesn't support pipeline promotions.

[douglascayers]

@mars @wadewegner Thanks for follow up, and you all bring up great points.

Regarding heroku.yml, I agree we need to wait on adopting that format until it supports Review Apps and Pipeline promotions. Mainly because Review Apps is the "killer feature" of Salesforce DX in this buildpack by using scratch orgs as the "Heroku disposable app".

The sfdx.yml file (format explained here) is not specific to Heroku but rather to another awesome utility by Wade to one-click deploy a Salesforce DX project to a scratch org environment (akin to the Heroku buttons).

A concern I have with this buildpack using sfdx.yml for some of the configuration is that the buildpack does not support all of the configuration options of sfdx.yml, like loading data plans or assigning permission sets. I'm afraid that people may expect this buildpack to respect all of the sfdx.yml properties and behaviors as a clone of the https://deploy-to-sfdx.com site. If that is the direction you want to go, then we can open some enhancement request issues in this buildpack repo and we (the community) get to them as we can. If replicating the deploy-to-sfdx site's behavior is not the goal, then that's where I think consolidating the configuration values into the one app.json file may reduce confusion or help manage expectations.

Side note, I've spent all day diving into Heroku Pipelines with Salesforce Buildpack for new curriculum for Trailhead, great stuff!

[wadewegner]

If there’s stuff missing from sfdx.yml then I’d almost rather include it than entirely switch to app.json. File specific bugs on items missing?

One option for the future would be to include an “import” of sorts in heroku.yml so that you can use values defined by other systems and easily “import” them such that you can use a Heroku construct in the buildpack to get the values.

[wadewegner]

@devarispbrown and @ike-delorenzo it'd be good to know when heroku.yml will be at a point where we can decide to move functionality currently in sfdx.yml and then update the buildpack.