Don't run on commit to main (#6)

* Don't run on commit to main
* add notes to readme
Signed-off-by: vsoch <vsoch@users.noreply.github.com>

.github/workflows/builder.yml

@@ -2,8 +2,11 @@ name: singularity-deploy
 
 on:
   push:
+    # This branch does not exist! You should update this to be your "production" branch
+    # and ensure that when you work on recipes you only merge to this branch when it's time to release
+    # You can also use another GitHub trigger entirely
     branches:
-      - "main"
+      - "main-branch"
 
 jobs:
   release:

README.md

@@ -17,6 +17,10 @@ Yes and no. Note that assets are limited to 2 GB in size, which is still fairly
 it as a template for your own recipes as is, or modify it for your custom
 use case. Instructions are below!
 
+**Note** Currently recipe extensions are associated with tags, and the GitHub release is
+associated with a digest. We likely will change this in the next few weeks so that GitHub
+releases are tags, and the "digests" are flie names. Stay tuned for updates!
+
 ## Getting Started
 
 ### 1. Template or Fork
@@ -38,7 +42,10 @@ or an organizational namespace.
 First, you should write your container recipe(s) in the present working directory.
 For good practice, when you are updating recipes you should checkout a new branch
 and open a pull request, as the repository comes with a workflow to trigger on a PR
-to [test your container build](.github/workflows/test.yml). You can add any additional
+to [test your container build](.github/workflows/test.yml). Note that in the main workflow
+that deploys the releases, the current branch is set to be `main-branch`. You should
+update this to be your main "production" branch that you want to deploy releases on merge.
+You are also free to choose a different trigger and release strategy. You can add any additional
 tests that that you might need. By default, any Singularity.* file will be automatically detected. 
 If there is no extension (the name Singularity), the name used will be "latest." 
 You can use these tags across multiple releases of your containers. For example,
@@ -63,7 +70,7 @@ names, so you should not repeat the same tag. Do not use `:` in your tag names.
 If you do need to re-release a tag (not recommended if a user might be using it and then it's changed) you can manually delete
 the release and the tag in the GitHub interface. This is a nice structure because it
 means you can have containers with different names under the same tag. In the example
-above, we have each of "deploy," "latest," and "salad" released under tag 0.0.1.
+above, we have each of "pokemon," "latest," and "salad" released under tag 0.0.1.
 This is how it looks on GitHub:
 
 ![img/releases.png](img/releases.png)