Why is it necessary to tear down resources in the workflows?

[devantler]

I just noticed that both GitHub Action workflows tear down resources after executing their job. Out of curiosity, I am interested in knowing why? I never thought this was required, as I assumed that the worker is automatically killed/cleaned up after a run. Is this a wrong assumption? Please enlighten me 🙏🏻😃

[sleiner]

I assumed that the worker is automatically killed/cleaned up after a run.

Your assumption is correct 😊 Still, there are a few reason I included it as a step:

• At the end of the job, we are caching .vagrant.d/boxes (to avoid running into the rate limits of vagrantcloud.com by downloading to Ubuntu image to often). Even though I reckon that running VMs do not write to that directory, I wanted to make sure that there are no unforeseen side-effects there.
• A proper teardown is something that should work. You can leave it out if your whole environment is teared down anyway, but especially when testing locally, it is important that a proper teardown works. So I regard the fact that it works a feature which is verified in CI.

Upon switching to molecule in #67, we will drop the explicit destroy step as molecule already does this as part of its regular test scenario.

PS: We will still have a prune which deletes outdated images to keep the cache size as low as possible ;-)

[devantler]

Thanks for the insights!

I had not thought about the implications of testing the workflow locally, and ensuring the cache is maintained.