Consider versions stored in filesystem

[sethphillips]

i've always considered committing to git in the CI process to be fraught with peril. I would think the sensible default to be storing the version manifest on a remote filesystem. Perhaps possible to pull the version from that remote disk as part of the push process so that a version history could be maintained?

[Sammyjo20]

Hi @sethphillips, thanks for your support via coffee! I'm glad Lasso works well for you. This was actually quite a challenging aspect to Lasso. I agree with you and wouldn't personally commit anything while in the CI process - this is why I added the "--no-git" flag. This creates the lasso-bundle.json file on the Filesystem rather than locally in the project, but it's challenging to keep track of versions.

Perhaps to add versioning without requiring you to commit the file, Lasso could keep track of the current commit that CI is working on, and then download the bundle relating to that. This would then help solve the rolling-back issue, and if we already have assets for a certain commit-code, we skip rebuilding and just tell CI that it's already been completed.

What do you think? Do you have any other suggestions to help with this discussion?

Thanks again for using Lasso!

[sethphillips]

im trying to fully wrap my head around the process of the rollback.
You're counting on a quick commit rollback and re-pull the previous zip from the committed bundle.json in version control? I guess in that scenario CI doesn't come into play at all whereas in most of the systems I work on a rollback would actually entail another CI build with the committed changes.

[Sammyjo20]

Yes that's exactly how it works. It only checks the history on the "pull" command. I was naieve of the other approach - where CI will also be run again during a roll back. In that case, Perhaps by default, it should check the version before compiling and if it sees that a bundle has been created for that commit hash, it will just skip the build process?

I'd say that's a pretty solid improvement. We could also tie the versioning to the commit hash rather than simply the number of bundles that has been created. This would then solve the isse where you can't have versioning without Git. I love it.

[asbiin]

Hello. I had the same kind of questions. I would like to use lasso, but with the --no-git option.

I was thinking of a way to associate the generated zip file with a git commit number, or a git tag version. This way, when pulling the files, it's possible to either

• get the file using the git commit number
• or using the last tag version (it might not be up to date, but it's better than nothing)

The lasso-bundle.json file can be suffixed with the commit number, or the tag version, so we can get it, and multiple json files can point to the same asset zip file.

[Sammyjo20]

Hi guys, apologies for the delay on this issue. I'm going to be spending a bit more time on Lasso over the next coming weeks as I've got a few PRs here to merge in and I have a few v1.5/2 ideas that I want to work on.

On this issue, there's a PR open that appends the git commit hash onto the lasso-bundle file to help improve Lasso in this scenario. I'm also going to be building in an option where Lasso will append the environment name onto the bundle so this is tracked better within git.

See #51 for more