Sync targets

[paradoxuum]

Closes #40

Implements the following sync targets, specified through asphalt sync --target <target>:

• cloud (default): Upload assets to Roblox
• studio: Sync the assets to Studio's content folder under a folder called .asphalt
• debug: Sync the assets to a folder in the working directory called .asphalt-debug

A --dry-run flag has also been implemented for the sync command, which will skip asset syncing and only output what assets will be synced.

Code generation functions have been altered slightly to accept a BTreeMap<String, String> instead of a Lockfile. This is because FileEntry requires integer asset IDs whereas local syncing generates a string ID that points to a path in the content directory.

[jackTabsCode]

@paradoxuum I've noticed that if you sync an SVG, even though we're converting the data, it's still being saved with the SVG extension, so it can't be opened and probably won't work in Studio either. We need to make sure we use the correct extension when syncing and uploading.

This wasn't a problem with the "cloud backend" before because the Roblox asset name doesn't matter, but no matter the target, if you upload i.e. a image.svg it should be "synced" as image.png

[jackTabsCode]

Note-I wouldn't hardcode this just for svgs. I plan to support other audio formats in the future that convert to ogg.

[jackTabsCode]

• Can we get a README update as part of this PR?
• Can I get more information on how the lockfile comes into play with these targets? I know we had some discussion about it, but I'd like it to be documented.

[jackTabsCode]

I'm also starting to ponder over whether asset uploading should still be in asset.rs and upload.rs. Things felt a little bit split before because the asset impl decides how to upload an asset, upload.rs has functions for uploading to Open Cloud and the legacy API, and now backend.rs also decides where to put files.

Perhaps asset.rs could only be responsible for preparing an asset (such as file conversion or alpha bleeding). That might make things simpler. The control flow of the program seems like it's getting slightly convoluted.

What do you think?

[paradoxuum]

Perhaps asset.rs could only be responsible for preparing an asset (such as file conversion or alpha bleeding). That might make things simpler. The control flow of the program seems like it's getting slightly convoluted.

Yeah I was thinking the same when writing the PR, I think everything uploading/writing related should be in backend.rs. I think the asset's data should be exposed through a getter (i.e. asset.data()) and then the backends can upload or write the data.

[jackTabsCode]

Perhaps asset.rs could only be responsible for preparing an asset (such as file conversion or alpha bleeding). That might make things simpler. The control flow of the program seems like it's getting slightly convoluted.

Yeah I was thinking the same when writing the PR, I think everything uploading/writing related should be in backend.rs. I think the asset's data should be exposed through a getter (i.e. asset.data()) and then the backends can upload or write the data.

You could also split up the backend files per target so that the files don't get too long.

[paradoxuum]

• Can we get a README update as part of this PR?

Yep, should this be formatted similarly to Tarmac's README?

• Can I get more information on how the lockfile comes into play with these targets? I know we had some discussion about it, but I'd like it to be documented.

Currently, assets with existing hashes will be skipped with the cloud target only. This is ideal because in the scenario that all of your assets are synced, no assets will end up being synced with the studio or debug targets. This is more important for the debug target, but it can also be important for the studio target if you have a slow connection and want to load all of your assets quickly.

Since the cloud target is the only one that deals with the lockfile, it also means that the lockfile is only written to when using this target.

[jackTabsCode]

Can we get a README update as part of this PR?
Yep, should this be formatted similarly to Tarmac's README?

Nah, I just mean add documentation for the target and dry run options and keep our current format.

[jackTabsCode]

After testing, it looks like old files in the debug or studio folders aren't removed. This could build up over time and take up a lot of space. I would say clear the directories, but my only concern is that, in the case of Studio syncing, if you have two projects synced locally to Studio, that'd be an issue.

Perhaps we could clear them, but suffix the folder name with the root folder's name. So, .asphalt-{folder-name}?

[paradoxuum]

Perhaps we could clear them, but suffix the folder name with the root folder's name. So, .asphalt-{folder-name}?

There could also be a name field in asphalt.toml (i.e. a project name), but that's probably out of scope for this PR (and maybe unnecessary). I think using the folder name the asphalt.toml file is in probably works.

[paradoxuum]

Nah, I just mean add documentation for the target and dry run options and keep our current format.

I made some changes to the asphalt sync section in commit ac8b3f0. I also changed the description of the sync command to "Sync assets" since "Sync assets to Roblox" only applies to the cloud target. I feel like that probably isn't descriptive enough, though I'm not sure if it needs to be.

[jackTabsCode]

Awesome! Could you resolve the merge conflicts @paradoxuum

[jackTabsCode]

After testing again, I've found another issue (Sorry!). This might require more thought to fix. We need to pull animation IDs from the lockfile when syncing to a Studio target, or else, if the user's game is expecting animations, it will break.

[paradoxuum]

After testing again, I've found another issue (Sorry!). This might require more thought to fix. We need to pull animation IDs from the lockfile when syncing to a Studio target, or else, if the user's game is expecting animations, it will break.

Should be fixed now, the change moves the lockfile check to the backends which removes the hard-coded check for the cloud target as well.