You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was one thing that tripped me up, while making a custom blueprint, initially the tests weren't properly working, I soon discovered this was because of the fact that blueprints are disambiguated by name.
It's a bit of a foot gun in my opinion, so I'm proposing that the implementation instead hashes these blueprint contents, and then generates them via their hashes, so that any duplicate deployment is deduplicated by their eventual instructions and contents, instead of the name.
I'm using "hash" loosely here, but "an identifier depending on the contents" would work as well.
The text was updated successfully, but these errors were encountered:
I had a look at the way complement constructs blueprints, and there may be a side-effect due to the absence of this; If a blueprint is edited, the changes will not immediately propagate, due to the fact it caches on the name, not the contents of the blueprint.
In other words, if someone alters a blueprint while testing, they will get bugs due to complement still using the old image, only a docker system prune will remove that named image from the cache.
This was one thing that tripped me up, while making a custom blueprint, initially the tests weren't properly working, I soon discovered this was because of the fact that blueprints are disambiguated by name.
It's a bit of a foot gun in my opinion, so I'm proposing that the implementation instead hashes these blueprint contents, and then generates them via their hashes, so that any duplicate deployment is deduplicated by their eventual instructions and contents, instead of the name.
I'm using "hash" loosely here, but "an identifier depending on the contents" would work as well.
The text was updated successfully, but these errors were encountered: