Tracking our first production recipe run

[cisaacstern]

The first production run of this feedstock (and indeed, our first automatically-triggered production run ever) is now running. Its progress is tracked here:

https://pangeo-forge.org/dashboard/recipe-run/26

Here are some notes on user experience, registration bugs, etc. that I've noticed in starting this run:

• Unlike for recipe tests of staged-recipes PRs, @pangeo-forge-bot does not currently post a notification about production builds for merged feedstocks. Perhaps in the future, the bot should open an Issue like this on the associated feedstock, with details about the run such as a link to the recipe run page (as provided above).
• On the linked recipe run page, I notice that the version is incorrectly provided as "0.0". I'll fix that to reflect the actual tag from which the run was triggered.
• Similarly, I've triggered the run from the tag (and not a commit sha). This tag ended up as the value of the recipe run table's head_sha field. This should be corrected as well.

[rabernat]

• Unlike for recipe tests of staged-recipes PRs, @pangeo-forge-bot does not currently post a notification about production builds for merged feedstocks.

This might be a good use for the github deployments. Ideally we could just link a user back to a page on pangeo-forge.org that has all of the feedback / info about the attempted run. This would probably require https://github.com/pangeo-forge/pangeo-forge-orchestrator/issues/62.

• On the linked recipe run page, I notice that the version is incorrectly provided as "0.0". I'll fix that to reflect the actual tag from which the run was triggered.
• Similarly, I've triggered the run from the tag (and not a commit sha). This tag ended up as the value of the recipe run table's head_sha field. This should be corrected as well.

I think we should iterate a bit on whether it really makes sense to tie runs to repo tags. That was just an idea we had. But maybe just using commits would be easier. We already have a "version" in meta.yaml, and it seems confusing to also have a tag version.

[cisaacstern]

This might be a good use for the github deployments.

I like this idea.

And yes, switching to running from the latest commit of a push to the default branch makes sense. Should I just make that change or is there anything further worth considering about it?

[rabernat]

Just make the change to commits. It's clearly the right path to me.

[rwegener2]

The first production run of this feedstock (and indeed, our first automatically-triggered production run ever) is now running.

😱 I had no idea this was the first automatically triggered run!

[cisaacstern]

Just make the change to commits. It's clearly the right path to me.

This might be a good use for the github deployments. Ideally we could just link a user back to a page on pangeo-forge.org that has all of the feedback / info about the attempted run. This would probably require https://github.com/pangeo-forge/pangeo-forge-orchestrator/issues/62.

Both of these points

• trigger production runs on pushes to default branch of feedstock repo (not tags)
• use deployments to link users back to recipe run page

were implemented in https://github.com/pangeo-forge/registrar/pull/23. We can see a successful end-to-end demo of these features in this test repo, where clicking Deployed here:

brings us to https://pangeo-forge.org/dashboard/recipe-run/27.

This real feedstock (i.e. noaa-coastwatch-geopolar-sst-feedstock) also has a deployments page:

and similarly, clicking Deployed there brings us to https://pangeo-forge.org/dashboard/recipe-run/28. In the case of this real feedstock, the deployments API integration has worked in the sense in that it reflects the correct exit state (failed). In terms of why this production run has failed, the Prefect logs that are piped over to pangeo-forge.org aren't helpful (perhaps there are too many lines to full resolve them?). I've glanced at the logs on the Prefect backend, which tell a more complete story (with tracebacks, etc.) but diagnosing what's gone wrong there will have to wait until Monday.

So in sum, as of the time of writing this, we can now look for to the Environments sidebar header on any feedstock repo

and click through to the Deployments page to find a link to the latest production deployments, which link us to the associated recipe runs on pangeo-forge.org.

There are all sorts of aesthetic and clarity problems to clean up here but I don't think this issue is the right place to track them, so closing this.

[cisaacstern]

One last thought, it looks like conda-forge has the same "commit aesthetics" scenario we ended up with: regardless of who has contributed to the staged-recipes PR, the bot account is the one that is credited with all of the commits for creating the repo; e.g. https://github.com/conda-forge/pangeo-forge-recipes-feedstock/graphs/contributors