I am trying to wrap my head around the correct way...
# best-practices
n
I am trying to wrap my head around the correct way for projects and blocks to interact now that projects are a thing. I am wondering if anyone can shed some light on this for me. I will use our infrastructure as an example. Most of our deployments run on Google Cloud Run. Before, it made a lot of sense to create a
Cloud Run Job
block, save it, and reuse if in building our python
Deployment
objects. Now, it seems that a lot of the infrastructure is taken over by the work pool. If I create a
cloud run work pool
, what is the purpose of a
cloud run block
? I already have all of my infrastructure existing in code now and I don't really see why I should want to use a
cloud run block
. Other things like credentials still make a lot of sense for blocks. But some of them seem to be replaced by the new projects + work pools workflow. Am I missing something here? Or does anyone have some good insights into this they would be willing to share?
1
c
Hey Nelson! This is a good question and one we should document better; the short answer is that you are thinking about things correctly. • work pools and their corresponding workers are now "the" interface to your workflow infrastructure; this allows for a more principled separation of concerns. In theory one team could manage your work pools and create fully custom job templates for what infra config is accepted / allowed, and another team could author deployments that submit work to these work pools. • this means that blocks are no longer necessary for the purposes of deployment infrastructure management and configuration; some users may still have use cases for the cloud run block (and others) if they wanted to submit work to various infra providers from within their workflows, but otherwise they aren't strictly necessary for deployments • otherwise, in the context of deployments at least, blocks are best thought of as managed / shared server-side configuration and secrets. As you've seen, you can template your credentials and other portions of your deployment using blocks
n
@Chris White not sure if you are the right person for this, but as a note of feedback, I was very thrown off for a little bit working with projects and blocks that github credentials did not take a github credentials block. I had to create a secret block with the github access token. Idk if I just missed it in the docs or what. But that was a bit confusing for me.
thank you 1