Had a case where I knew there was a production failure, and had run a production sync before creating my branch (since the org was old and I changed the package.xml significantly).

Submitted the PR and waited for it to generate package.

Once complete, ran the "Deploy to Production (Selective Tests)" pipeline, whose first step was to resync.

Perhaps we could add a variable to skip syncing prod that can be enabled in cases where you very recently ran a sync? Would be helpful in more complex orgs that take some time to refresh.

after a merge we should remove the branch to clean it up

Deployments can be pretty slow in some cases and we can spend a lot of build minutes waiting for salesforce to finish doing it's things.

One thought would be the deploy can just submit it and store the deployment id as an artifact, and prompts a user to visit the deployment status page to monitor status. Optionally they could run a follow up 'Check Status' step that would validate the current status of the deployment.

Not really an issue until we start using this enough that conversing build minutes might be worth it ...

Custom labels are deployed in batch, which could be dangerous given they often differ in sandboxes and it doesn't match the general principle that this only deploys what changed.

Seems like this could be kind of tricky though

Ran on an org without an existing package.json and all sfdx commands start erroring out

Starting SFDX: Create Apex Class

23:43:06.877 sfdx force:apex:class:create --classname SomeClass --template DefaultApexClass --outputdir src/main/default/classes
ERROR running force:apex:class:create:  A name parameter is required to create a storage
23:43:07.828 sfdx force:apex:class:create --classname SomeClass --template DefaultApexClass --outputdir src/main/default/classes ended with exit code

see forcedotcom/salesforcedx-vscode#253 for a discussion of the underlying issue

would be good to add a default "name" attribute to the package.json. an easy option would be to pull the value of the parent folder, i.e. /users/myname/dev/proj_name would use proj_name for the name attribute

Same as #5, seems useful to have lightning stuff in here by default. Open to other opinions on this one ...

Running yo ccc yield changes even when there are none, due to whitespace differences between the generator output and the prettier for json/yml.

Would be nice to get this consistent so there is less noise when upgrading

In a few cases working on projects where all the deployments are handled by a separate process. Would be nice to have a config variable to disable the pull request automation so we don't generate extra build time.

if [ ! -z "$MANUAL_ONLY" ]; then ./sync.sh

If everyone is using source control syncing only when a pull request has happened seems efficient, but when working on projects where other devs are working outside the repo it's helpful to sync this on a schedule. Update the instructions to recommend this.

Might be worth making this standard as we expand base metadata to include stuff, i.e. custom fields, that are typically modified in production directly.

force-source-clean and sfdx-git-packager

bonus points for ensuring these get auto-updated

at time of writing this we could be using
"prettier": "^2.8.0",
"prettier-plugin-apex": "^1.11.0",
"pretty-quick": "^3.1.3",

As we start to track more and more metadata, our pipeline is going to slow down.

In theory, we could generate a package.xml from only the inbound changes and then use that to sync master from production.

We could have a nightly process (4am) that runs to do a full sync. OR, if we wanted to get fancy, we could have the pipeline check for when the last full sync was, and run a full sync if it's > X days.

Either way, we will need to modify the build package script to look something like this:

git checkout $pr-branch
git merge master
sfdx git:package -d dist/pgk
git checkout master
sfdx force:source:retrieve -x dist/pgk/package.xml
git add .
# I guess if there are ANY changes then we could commit to master and abort?  
# Or would it make more sense to commit / merge master into $pr-branch again 
# and see if there are conflicts?  
# I guess there could be changes that will merge?

Would be a great clutter saver. Guessing an option to disable in the global pipeline settings would be beneficial

Probably being overly OCD here, but would be nice if the deploy directory got purged every once in a while, maybe part of the npm run clean?

NB: thsi requires a feature to be enabled in the org see "Enable the ExperienceBundle Metadata Type" in https://developer.salesforce.com/docs/atlas.en-us.communities_dev.meta/communities_dev/communities_dev_migrate_expbundle.htm

This is needed so references to lightning components are included in default metadata we retrieve.

Before the Summer ’19 release (API version 45.0 and earlier), the Network, CustomSite, and SiteDotCom metadata types combined to define an Experience Builder site. However, retrieving the SiteDotCom type produces a binary .site file that isn’t human readable. By retrieving the ExperienceBundle type instead of SiteDotCom, you can extract and edit granular site metadata in a human-readable format, contained in a three-level folder structure.

we currently have husky 7.x installing, the docs are weird about it, and imply that nothing breaks until v8, but it sure seems like it's busted for new projects

migration is fairly simple for existing projects

npm install husky@latest --save-dev \
  && npx husky-init \
  && npm exec -- github:typicode/husky-4-to-8 --remove-v4-config

the resulting format can then be incorporated into the yo generator

Currently if you run either of the manual deploy options it goes straight to prod if it's successful. Would be nice if it just validated and then we could quick deploy if we're ready.

Accidentally deployed expecting the same pattern of build/validate/quick deploy to happen as the primary pipeline. Not that the name of the pipeline wasn't clear about the action.

This also opens up letting the client quick deploy, and just validating work in progress that you're not ready to deploy (so you know it'll deploy on the deploy date).

`➜ ccc-sfdc git:(upgrades) ✗ yo ccc

 _-----_     
|       |    ╭──────────────────────────╮
|--(o)--|    │    Callaway Cloud SFDX   │

---------´ │ Project │ ( _´U_ ) ╰──────────────────────────╯
/A\ /
| ~ |
'..'_
´ |° ´ Y

conflict package.json
? Overwrite package.json? overwrite
force package.json
conflict manifest/package.xml
? Overwrite manifest/package.xml? overwrite
force manifest/package.xml
identical .vscode/launch.json
conflict .vscode/settings.json
? Overwrite .vscode/settings.json? overwrite
force .vscode/settings.json
conflict bitbucket-pipelines.yml
? Overwrite bitbucket-pipelines.yml? overwrite
force bitbucket-pipelines.yml
create build/format-commit.sh
create build/known-metadata-issues.md
identical build/merge.sh
identical build/package.sh
conflict build/pipelines-setup.md
? Overwrite build/pipelines-setup.md? overwrite
force build/pipelines-setup.md
identical build/schedule.sh
identical build/setup.sh
identical build/sync.sh
Installing sfdx force-source-clean
This plugin is not digitally signed and its authenticity cannot be verified. Continue installation y/n?: y
Finished digital signature check.
warning ../../../package.json: No license field
Installing plugin force-source-clean... installed v0.1.0
Installing sfdx sfdx-git-packager
This plugin is not digitally signed and its authenticity cannot be verified. Continue installation y/n?: y
Finished digital signature check.
warning ../../../package.json: No license field
Installing plugin sfdx-git-packager... installed v0.3.3

I'm all done. Running npm install for you to install the required dependencies. If this fails, try running the command yourself.

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/prettier
npm ERR! dev prettier@"^2.x" from the root project
npm ERR! peer prettier@">=2.0.0" from [email protected]
npm ERR! node_modules/pretty-quick
npm ERR! dev pretty-quick@"^3.x" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer prettier@"^1.17.0" from [email protected]
npm ERR! node_modules/prettier-plugin-apex
npm ERR! dev prettier-plugin-apex@"^1.x" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: [email protected]
npm ERR! node_modules/prettier
npm ERR! peer prettier@"^1.17.0" from [email protected]
npm ERR! node_modules/prettier-plugin-apex
npm ERR! dev prettier-plugin-apex@"^1.x" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /Users/ralphcallaway/.npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR! /Users/ralphcallaway/.npm/_logs/2022-07-16T12_05_49_694Z-debug.log`

Not super common, but no harm in adding it if there is nothing in the org.

unfortunately, in the pipeline, you can only configure which PR to run based on the target branch (not the destination).

 pull-requests:
    "**":

I think the best solution is just to check if the BITBUCKET_PR_DESTINATION_BRANCH is master and exit if not.

Right now, if you were to run the full pipeline on a PR into a branch other than master it would likely break or, worse, deploy something unexpectedly into master.

Scenario (intentionally simplified for demonstration purposes)

• master branch just has apex classes
• you create a feature branch for some new apex
• to get it working right you need to alter an workflow field update, which you add to the manifest

Current Behavior
field update would get deployed as if it's new, which gets the job done functionally, but we lose the history of that component, and can't tell what is was before, and what part got modified, which is very useful in a rollback, or forensic analysis of why something is in a particular state

Workaround
before merging the feature branch, update the manifest in master, current sync and merge will take care of everything

Ideal Behavior
before merging the feature branch, incorporate new components (to the manifest, not necessarily the org) into master prior to performing the sync

Discussion
kind of tricky, we'd want to ensure

1. manifest changes and the files they reference only get into master if the merge succeeds
2. need to merge the manifest changes from feature into master, not just overwrite (i.e. can't just do git checkout feature -- manifest/package.xml which just overwrites)
3. we need to consider stuff getting added or removed from the manifest
4. we might need to deal with fact git xml merge isn't smart enough and do something specific to the manifest format (not covered in example)

Rough Attempt
Very likely there are things missing, bugs, and opportunities for simplification, but shows the concept

# 1. master_sync.sh
same as sync.sh

# 2. manifest_sync.sh
git checkout -b temp_feature master # temp master to stage merge 
git merge $BITBUCKET_BRANCH # merge the feature
git checkout -b master_with_manifest master # create sync branch
git checkout temp_master -- manifest/package.xml # pull merged manifest into sync branch
sfdx force:source:clean -n
git commit -am "[skip ci] Auto-Pull of Production with $BITBUCKET_BRANCH manifest" || echo "No changes to commit"
# no push, it'll get incorporated when the merge happens, and no need to create any branches we'll just have to delete later

# 3. package.sh
git checkout $BITBUCKET_BRANCH
git merge temp_master
sfdx git:package -d dist/$BITBUCKET_BRANCH -s $BITBUCKET_BRANCH --purge

# 4. merge.sh
no changes

nice to have, would avoid having xml come back differently on clean than what was typed in. mainly happens for manifest/package.xml

So many standard objects, let's build a bigger list. Bonus if there is someway to do this dynamically during the yo ccc run so future standard objects automatically get pulled in. Only really matters for standard objects that support adding custom fields

The launch.json and settings.json files in the .vscode folder are useful to have in the repository to ensure everyone has the same functionality enabled ... these appear to be ignored (could just be an artifact of an earlier version of the generator)

As i've started to use git:package more I'm always accidentally editing the file in the deploy directory not the one in the sfdx package directory.

Related to forcedotcom/cli#37

If doing a single stage deployment pipeline this can cause serious issues as the pipeline will think the deployment has gone through when it really has not updated salesforce.

This results in the branch being merged into master.

However, when the next pipeline runs, it will sync with salesforce and overwrite the merged changed with the actually state of salesforce.

If the person setting this up is different than the person working day to day on the project it's easy for upgrades to get missed.

One approach could be to add a version check to the push hook that happens on a monthly interval. If a new version is available the push gets rejected with an informative message. Since it would only happen once a month, if upgrading at that time isn't desired the push can just be repeated. This seems like a fairly small decrease in ergonomics for keeping people upto date. Likely to be other solutions.

Might be nice to run a sfdx force:mdapi:deploy --checkOnly -l NoTestRun automatically on PR so that we know that all the required metadata is included as soon as the PR is opened.

Two reasons this might not be a good idea:

1. Additional Deployment minutes. While it would typically be very quick, i guess if there was another deployment in the queue it could eat a lot of minutes.

2. I'm not actually sure this is possible. -l NoTestRun might not work against a production org

Thinking it might be a Windows 10 specific issue, but after running all of the setup steps in my repo on Windows 10 and deploying to bitbucket, I was getting a an error trying to run production sync:

+ ./build/setup.sh
bash: ./build/setup.sh: Permission denied

Resolved this by running the following git CLI commands, committing, and pushing to master:
git add --chmod=+x -- build/sync.sh
git add --chmod=+x -- build/setup.sh
git add --chmod=+x -- build/schedule.sh
git add --chmod=+x -- build/package.sh
git add --chmod=+x -- build/merge.sh

Not sure if this was an issue for every file, but just figured I would add do it for all to be safe.

version: 1.1.0

would be nice if the new lines didn't get chomped, better ergonomics :-p

if you start with this

# yarn files
yarn-debug.log*
yarn-error.log*

# sfdx git:package deploy artifacts
deploy
dist

# MacOS system files
.DS_Store

you end with this (new lines get chomped)

# yarn files
yarn-debug.log*
yarn-error.log*
# sfdx git:package deploy artifacts
deploy
dist
# MacOS system files
.DS_Store

https://code.visualstudio.com/docs/editor/extension-marketplace#_workspace-recommended-extensions

allows us to setup a new workspace in vs code by just installing all recommnded extensions

key list

• salesforce pack
• prettier

maybe list (if we want more general recommendations, i'm sure there could be tons on this list)

• project manager
• git graph
• git lens
• live share
• salesforce reference

Upgraded to the latest and got this error
Entity type 'LightningComponentBundle' is not available in this api version

Per this forum the culprit is the sourceApiVersion in sfdx-project.json

Would be nice to add an update to keep that api version current with each upgrade. Could be other options like a pre-commit hook to check things are up to the latest version. Would be nice not to have to release a new generator version 3 times a year to bump api versions. Got to be something better we could do or some way to get the latest released version of the salesforce api.

Every once in a while a deployment doesn't work out. Then comes the rollback.

It would be pretty sweet if we could make that entail only clicking one more "Run" on the pull request pipeline. There could even be some value of immediately validating the rollback once the pull request is merged allowing speedy rollbacks when you hear of issues.

Right now we completely overwrite package.xml. We really need to merge instead.

This will make it easier to upgrade, but keep project specific items like additional standard objects, email templates, etc.

Seems like if we're pulling down flows this might be good to incorporate. Might need to add standard objects in addition to the * for custom object workflow. I'm sure there are different opinions on this ...

v: 1.0.8

ran with an existing project, got the following prompts, none were for .gitignore ...

? ==========================================================================
We're constantly looking for ways to make yo better! 
May we anonymously report usage statistics to improve the tool over time? 
More info: https://github.com/yeoman/insight & http://yeoman.io
========================================================================== No

     _-----_     
    |       |    ╭──────────────────────────╮
    |--(o)--|    │    Callaway Cloud SFDX   │
   `---------´   │          Project         │
    ( _´U`_ )    ╰──────────────────────────╯
    /___A___\   /
     |  ~  |     
   __'.___.'__   
 ´   `  |° ´ Y ` 

   create package.json
   create .prettierrc
 conflict .vscode/settings.json
? Overwrite .vscode/settings.json? overwrite
    force .vscode/settings.json
   create bitbucket-pipelines.yml
   create build/merge.sh
   create build/package.sh
   create build/pipelines-setup.md
   create build/setup.sh
   create build/sync.sh
 conflict manifest/package.xml
? Overwrite manifest/package.xml? overwrite
    force manifest/package.xml


I'm all done. Running npm install for you to install the required dependencies. If this fails, try running the command yourself.```

Add a default launch.json so it's easy to debug apex

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
      {
        "name": "Launch Apex Replay Debugger Current File",
        "type": "apex-replay",
        "request": "launch",
        "logFile": "${file}",
        "stopOnEntry": true,
        "trace": true
      },
      {
        "name": "Launch Apex Replay Debugger",
        "type": "apex-replay",
        "request": "launch",
        "logFile": "${command:AskForLogFileName}",
        "stopOnEntry": true,
        "trace": true
      }
    ]
  }

would be nice to have to make sure everyone is running the latest project config.

Might not be worth the effort