Build to AWS S3?

[chuck_agari]

I've run across a couple of discussions that I think might be related, but I am highly unqualified to understand them because I am barely peripherally familiar with S3. And yet, it looks like, because our company's applications are hosted on S3, we're going to use s3 (or S3 buckets, I think the right term is) for online help storage and serving. Has anyone else used this, and if so, how.

I have an account and a test bucket. I can, apparently, simply drag a copy of an output folder into that bucket. If it works, great. If the engineering team can easily figure out how to "hook" into that from the application, great. I'm assuming that it simply serves up the help system the same way it does the application.

I'd love to automate this. I found one product called TntDrive (https://tntdrive.com/faq.aspx) where you can apparently map a local folder to an S3 bucket ($60), and another called S3 Browser (https://s3browser.com/amazon-s3-folder-sync.aspx) that apparently lets you synchronize a folder to an S3 bucket (free). The latter seems like, once it was set up and configured, it might work perfectly--except I think Flare always deletes an output folder and re-creates it when it re-builds a target. This brief...disruption...seems to have totally confounded Github Desktop when I tried using it to sync an output folder to a Github repo.

So, what do y'all who are working with S3 do?

[jjw]

This seemed quite good:
https://www.cloudberrylab.com/explorer/amazon-s3.aspx

I particularly liked the file comparison tools - but I only used it briefly because my stingy work wouldn't fork out the $39. Bah humbug.

[Psider]

The latter seems like, once it was set up and configured, it might work perfectly--except I think Flare always deletes an output folder and re-creates it when it re-builds a target. This brief...disruption...seems to have totally confounded Github Desktop when I tried using it to sync an output folder to a Github repo.

Regarding this bit, I'd suggest using the publish function which doesn't delete the destination folder contents. (Note I don't use S3, but the theory is sound. )

So generate where you are now. Publish to a staging folder. Staging syncs to S3.

[chuck_agari]

The latter seems like, once it was set up and configured, it might work perfectly--except I think Flare always deletes an output folder and re-creates it when it re-builds a target. This brief...disruption...seems to have totally confounded Github Desktop when I tried using it to sync an output folder to a Github repo.

Regarding this bit, I'd suggest using the publish function which doesn't delete the destination folder contents. (Note I don't use S3, but the theory is sound. )

So generate where you are now. Publish to a staging folder. Staging syncs to S3.

Hm, perhaps the better solution would be to publish to source control. Like many shops, we use Git/GutHub (I hatehatehate Git), so the challenge would be configuring it all.

[Psider]

I personally wouldn't publish the output to source control.

People tend to want to do it so they can get a specific output when they need it, but you can do that from the source if necessary. Plus, you have to manually check out the output before you can publish. And you can get conflicts, which then introduce a merge risk, as well as massively slowing down the process when you have to check if it's an actual difference that matters or simply a date change or something. And sometimes the devs get upset about it as well, because it's output, not source.

[chuck_agari]

I personally wouldn't publish the output to source control.

People tend to want to do it so they can get a specific output when they need it, but you can do that from the source if necessary. Plus, you have to manually check out the output before you can publish. And you can get conflicts, which then introduce a merge risk, as well as massively slowing down the process when you have to check if it's an actual difference that matters or simply a date change or something. And sometimes the devs get upset about it as well, because it's output, not source.

Well, I have succeeded in both binding my project, which is my entire content repository, to a GitHub repository (a new one, because of the stupid bug where you can't use a new GitHub repo if you added a readme), and also successfully defined a folder structure separate from my Output folder (but still within my project, despite the warning in http://help.madcapsoftware.com/flare201 ... ations.htm to "not publish your output into your source folders (Content or Project). It is always best to publish output outside your main project folder altogether. Otherwise, you might lose your source files" because if you try to publish to a folder outside your bound project, you lose the source control information), creating 2 destinations to 2 Publish folder subfolders, associating each to my 2 HTML5 targets, and published both successfully. I did not have to do anything manually, and the output appeared in a GitHub subfolder perfectly, just as if I'd copied it from my local drive and pasted it there.

[Psider]

Well, good luck. You're treading new ground

[chuck_agari]

Well, good luck. You're treading new ground

It's what I do.

Seriously, I find working with dumbed-down products annoying. Screen real estate-wasting ribbons are just one example. And why, pretty much no matter what content development tool I've worked with over the years, I've had to dig into and fix the code because the product did something "helpful."

Meanwhile, while I'm thinking that being bound to source control via a VM is slowing Flare down horribly, I've not only pushed changes to source successfully to GitHub, I've also published updated targets successfully to GitHub. And with the exception of Flare not ignoring the stupid Mac OS .DS_Store files even after I added *.DS_Store to .gitignore, I've been successful so far doing all the soucre control tasks through the Flare UI.