Skip to content
This repository has been archived by the owner on Nov 28, 2020. It is now read-only.

php app/console assets_version:set:random ? #6

Closed
rafaelschmitt opened this issue Mar 27, 2015 · 2 comments
Closed

php app/console assets_version:set:random ? #6

rafaelschmitt opened this issue Mar 27, 2015 · 2 comments

Comments

@rafaelschmitt
Copy link

Hi, nice bundle ;)

What we would need is to set a generated random string as assets_version (could be a random hash string, 16-bit or 32-bit long).

So could you enhance your bundle with a "random-feature"? Something like this would be cool:
php app/console assets_version:set:random
(example) This will set assets_version to 9f37061554108afb4d884ee651585259

Our problem is, that we every time deploy a fresh release and our parameters.yml always still the same (until new parameters for new feature come in). So auto-increment doesn´t help us here. But we need a automated changing of assets_version. So generating a random hash string on every release would be our solution.

sorry for bad english;) Bye

@kachkaev
Copy link
Owner

Hi @rafaelschmitt!

How about this?

$ RAND=$(cat /dev/urandom | env LC_CTYPE=C tr -cd 'a-f0-9' | head -c 32)
$ app/console assets_v:set $RAND
Setting parameter assets_version in assets_version.yml to 'a3bbc4645d5f078712ec73e1f4c90907'...
Done. Clearing of prod cache is required.

You can find out more about generating random strings here:
http://stackoverflow.com/questions/2793812/generate-a-random-filename-in-unix-shell

I am deliberately not adding assets_version:set:random command because I don’t find it safe. Although you can generate pretty long sequences of characters, there is still a chance of hitting the same value. If auto-incrementing of assets_version does fit the needs of your project, I’d recommend using a more controlled value. For example, this can be the current timestamp:

$ app/console assets_v:set $(date +"%s")
Setting parameter assets_version in assets_version.yml to '1427469781'...
Done. Clearing of prod cache is required.

@rafaelschmitt
Copy link
Author

Ok, thank you for your fast and clear answer ;)
This will help us a lot. And you are right, a random hash would be not really safe -> chance of hitting same value.

We will use a combination of timestamp + short hash. Only timestamp would be unsafe for us, because there is a chance that two (or more) installations are started at the absolute same time.

Thanks ;)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants