@W-9625690@: Added github action to run heartbeat script against production plugin. - #478
Conversation
…ith separated commands.
| if: ${{ failure() }} | ||
| shell: bash | ||
| env: | ||
| SFDX_STATUS: ${{ steps.sfdx_install.outcome == 'success' }} |
There was a problem hiding this comment.
Could this output the steps.sfdx_install.outcome instead of converting to a boolean? That would provide more granularity on types of failures.
If we did this, we would want to change line 64 to be status: instead of succeeded:
There was a problem hiding this comment.
The granularity won't necessarily increase, because the possible states are "success", "failure", "cancelled", and "skipped". Steps that don't execute because a previous step failed will get the status "skipped", which feels like a misnomer to me but whatever.
Still, good point that the status can be a string now. I'll make that change.
| - name: Install SFDX | ||
| id: sfdx_install | ||
| # Sleep for 5 seconds between attempts, since it's possible that problems are network-related. | ||
| run: npm install -g sfdx-cli || (sleep 5 && npm install -g sfdx-cli) || (sleep 5 && npm install -g sfdx-cli) |
There was a problem hiding this comment.
I think it would be good to increase the timeout on the second sleep.
There was a problem hiding this comment.
Fair enough. What if we did an increasing backoff strategy, where the first timeout was 600 seconds (10 minutes), and then the second was 1800 seconds (30 minutes)? Or something similar but with different numbers?
| - name: Install Scanner Plugin | ||
| id: scanner_install | ||
| # Sleep for 5 seconds between attempts, since it's possible that problems are network-related. | ||
| run: sfdx plugins:install @salesforce/sfdx-scanner || (sleep 5 && sfdx plugins:install @salesforce/sfdx-scanner) || (sleep 5 && sfdx plugins:install @salesforce/sfdx-scanner) |
There was a problem hiding this comment.
Let's discuss at standup. I think we might want a different retry philosophy for code that we are directly testing versus code that we depend on.
| call %EXE_NAME% scanner:rule:remove --path test\test-jars\apex\testjar1.jar --force || exit /b 1 | ||
| echo "==== List the rules a final time, to make sure nothing broke ====" | ||
| call %EXE_NAME% scanner:rule:list || exit /b 1 No newline at end of file | ||
| call %EXE_NAME% scanner:rule:list || exit /b 1 |
There was a problem hiding this comment.
Just curious, any idea why the newline changed? There is nothing obvious in the script that I could see.
There was a problem hiding this comment.
I did the edits to the smoke test scripts manually this time, because regenerating the files can mess with the permissions and I didn't want to deal with that for such a simple change. I think the IDE manually added the newline at the end. It does that sometimes.
…ly disabled the PagerDuty alerts.
2 participants
My testing was done in a separate PR, #471, configured to run the script on command instead of on a schedule, and to send alerts to my personal PagerDuty service.
This is a link to a run where everything ran properly and no alerts were created.
This is a link to a run where the first attempt to install sfdx was replaced with
exit 1, forcing that attempt to fail. The second attempt succeeds, the test proceeds as normal, and no alerts are created.This is a link to a run where all three attempts to install sfdx were replaced with
exit 1, forcing that step to fail, and here's a screenshot of the alerts that were created.This is a link to a run where only
smoke-test.cmdhas been changed to always throw an error, and here's a screenshot of the alert that was created.This is a link to a run where only
smoke-test.shhas been changed to always throw an error, and here's a screenshot of the alert that was created.This is a link to a run after I started storing the
smoke-test-resultsfolder as an artifact. The jobs' artifacts have distinct names, and the Linux artifact only has one of the result files since it fails on the secondscanner:runcommand.