Merge pull request #2033 from radixdlt/remove-scrypto-install-script-…

…debug-logs

Remove scrypto install script debug logging

.github/pull_request_template.md

@@ -1,62 +1,46 @@
-## Summary
-```
-INSTRUCTIONS:
-Add summary - one or two sentences explaining the purpose of this PR.
-```
+> [!IMPORTANT]
+>
+> * Please read our [Contributing Guidelines](/CONTRIBUTING.md) before opening a PR.
+> * Before creating your PR, please ensure you read the [node branching strategy](https://github.com/radixdlt/babylon-node/blob/main/docs/branching-strategy.md), which is also used in this repository. The end result after completing the merge actions should be that `main <= release/XXX <= develop`, where `XXX` is the latest released protocol version. This ensures that we minimise merge conflicts, and that work doesn't go missing.
+> * As per the branching strategy, **you must ensure you select the _correct base branch_**, both for branching from, and in the PR UI above. The following process can be used to decide the base branch:
+>   * For code changes which can wait until the next protocol update to be released, use `develop`. This should be the default for code changes.
+>   * For code changes which need to go out as a fully-interoperable update to the node at the current protocol version, use `release/XXX`.
+>     * Such changes must be tested and reviewed more carefully to mitigate the risk of regression.
+>     * Once the change is merged, it is the merger's responsibility to ensure `release/XXX` is merged into the `develop` branch.
+>   * For github workflow changes, use `main`.
+>     * Once the change is merged, it is the merger's responsibility to ensure `main` is merged into both `release/XXX` and `develop`, so that the changes also apply to hotfixes, and to current development.
+>   * For changes to README files, use `main`.
+>     * Once the change is merged, it is the merger's responsibility to ensure `main` is merged into both `release/XXX` and `develop`, so that the changes also apply on these branches.
+> 
+> _Please remove this section once you confirm you follow its guidance._
 
-## Details
-```
-INSTRUCTIONS:
-Provide further details about the changes, or how they fit into the roadmap.
-You can delete this section if it's not useful.
-```
+## Summary
+<!--
+> [!TIP]
+> 
+> Start with the context of your PR. Why are you making this change? What does it address? Link back to an issue if relevant.
+> 
+> Then summarise the changes that were made. Bullet points are fine. Feel free to add additional subheadings (using ###) with more information if required.
+-->
 
 ## Testing
-```
-INSTRUCTIONS:
-Further details about the tests you've added or manually performed.
-You can delete this section if it's not useful.
-```
+<!--
+> [!TIP]
+> 
+> Explain what testing / verification is done, including manual testing or automated testing.
+-->
 
 ## Update Recommendations
-```
-INSTRUCTIONS:
-This section is to provide recommendations to consumers of this repo about how they
-should handle breaking changes, or integrate new features. The two key stakeholder
-groups are dApp Developers and Internal Integrators, and there are separate sections
-for each.
-
-In order to allow us to compile aggregated update instructions across PRs, please tag the PR
-with 0+ of the relevant labels:
-* scrypto-lib - Any change to the scrypto library
-* sbor - Any breaking change to SBOR encoding/decoding
-* manifest - Any change to manifest display, compilation/decompilation
-* transaction - Any change which affects the compiled manifest, or transaction semantics
-* substate - Any change to substates, the state model, or what's stored in the DB
-* native-blueprint-interface - Any change to the interface of native blueprints
-* files-moved - Any change to where engine types have moved, which will require
-  internal integrators to update their imports
-
-If you have a breaking change which doesn't fix into a category above, then tag it with
-the closest label, and discuss in slack/discord.
-
-If your PR contains no breaking changes or new features or hasn't been tagged, this whole
-section can be deleted.
-```
-
-### For dApp Developers
-```
-INSTRUCTIONS:
-Migration recommendations for a dApp developer to update their dApp/integrations
-due to to the change/s in this PR.
-
-These will be aggregated by the Developer Ecosystem team and included in the next Scrypto migration guide
-(eg https://docs-babylon.radixdlt.com/main/scrypto/release_notes/migrating_from_0.7_to_0.8.html )
-```
-
-### For Internal Integrators
-```
-INSTRUCTIONS:
-Instructions to any internal integrations (eg Node, Toolkit, Gateway, Ledger App) for how the changes may affect
-them and recommendations for how they should update to support this change.
-```
+<!--
+> [!NOTE]
+> 
+> This section is to provide recommendations to consumers of this repo about how they should handle breaking changes, or integrate new features.
+> 
+> If your PR contains no breaking changes or new features or hasn't been tagged, this whole section can be deleted. Add sub-headings if required for:
+> * ### Guidance for dApp Developers
+>   * Migration recommendations for a dApp developer to update their dApp/integrations due to to the change/s in this PR. This should include renames and interface changes.
+>   * Upon merge, please copy these instructions to an appropriate draft page under https://docs.radixdlt.com/main/scrypto/release_notes
+> * ### Guidance for Internal Integrators
+>   * Instructions to any internal integrations (e.g. Node, Toolkit, Gateway, Ledger App) for how the changes may affect them and recommendations for how they should update to support this change.
+>
+-->

scrypto-install-scripts/install-scrypto-macos.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 
-# Print commands and exit on errors
-set -ex
+# Exit on error
+set -e
 
 # Versions to install
 LLVM_VERSION=18