Using `main/elasticc` as the main branch for our ELAsTiCC broker

[troyraen]

This issue announces the designation of main/elasticc as the main branch for our ELAsTiCC broker. This issue will also track the branch's lifecycle.

• [ ] This issue should be closed when main/elasticc is either:
  • merged back in to develop,
  • spun off into its own repo,
  • or the decision is made to leave it here, and its existence is properly documented so that it can be found more easily. ~We may ultimately want to keep different main branches for code bases that run different surveys. In that case we could keep this naming scheme, so what is currently develop could become main/ztf.~ (ok, probably not)

Background / Motivation

The changes in PR #153 represent a logical first chunk in our development for ELAsTiCC. In addition, we have copied some of the broker's modules to the new pittgoogle-user where they will be used to run an independent pipeline in a separate GCP project, that will operate downstream from our ELAsTiCC broker. See #107.

Our ELAsTiCC broker and its development track is now considerably different from our ZTF broker. In addition, right now, our work on the ELAsTiCC broker needs to move quickly and nimbly. Thus, we are now designating main/elasticc as the main branch for our ELAsTiCC broker. This will allow our development for the ELAsTiCC broker to continue as an independent (sub)project -- with its own clear chain of PRs, etc. -- without cutting it off from this repo completely. We can decide whether/how to merge the two broker code bases after the ELAsTiCC broker design solidifies a bit more.

Plan for the immediate future

• [x] Next I am going to change the base branch on PR #153 from develop to main/elasticc. Right now those two branches are exactly the same, so this will not change anything about any of the code changes included in the PR. It just cuts the develop branch off so elasticc won't affect it (for now).
• [x] Then I am going to resolve the conflicts (just a couple of simple, random loose ends).
• [x] Then I will approve #153.
• [x] Then, @hernandezc1 should merge his PR (which at that point will be u/CH/test -> main/elasticc). Congratulations on a successful pull request 🎉 .
• [x] We will continue on from there with our development of the broker for the ELAsTiCC challenge -- treating main/elasticc as the main branch for the project. All work for this project should then be done in feature branches that are based on main/elasticc -- and thus we should open PRs for those feature branches that request to merge into main/elasticc.
• [x] ... and the first thing we should do from there is #165 (which I opened a PR for: #166)
• [x] ... and then add the IAM permissions (which I opened a PR for: #167 )

cc: @wmwv

[troyraen]

@hernandezc1 here's your next steps:

• Merge #153.
• Then review #166 (and approve it, if all looks ok).
• Then review #167 and test the deployment script that's included there.

[troyraen]

@wmwv @djperrefort @hernandezc1 @ap1605 Reminding you of, or introducing you to, this branch.

Our ELAsTiCC broker code mostly consists of a stripped-down version of our ZTF one (perhaps with some improvements like IAM permissions). It was very helpful to @hernandezc1 and I to do this during development. But perhaps now is a good time to consider merging this back into the main branch?

[djperrefort]

But perhaps now is a good time to consider merging this back into the main branch?

In general I think it is a good idea to keep the main branch as up to date and complete as possible.

[troyraen]

@hernandezc1 Now that we have multiple surveys going in the main (develop) branch, how about merging this branch back in there?