Hi all,
I'm trying to include an output folder for a target. The Source Control Guide for Git says this is possible (http://docs.madcapsoftware.com/Flare201 ... ideGit.pdf) "if using source control publishing," but I'm unsure of where to start/how to build a target that includes a destination.
Any pointers?
Thank you for your help!
Including Output Folder with Git Integration
-
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Including Output Folder with Git Integration
Welcome to the forums!
I can't give specific advice, but why would you want to add the output to source control? As the name says, that system is meant to store sources. There are not many reasons to include compiled artifacts in source control.
I can't give specific advice, but why would you want to add the output to source control? As the name says, that system is meant to store sources. There are not many reasons to include compiled artifacts in source control.
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
Re: Including Output Folder with Git Integration
Thank you, RamonS! I'm looking to host the output files alongside the sources on our server -- they'll be linked to from elsewhere (using iframes). I hope that makes sense!
Re: Including Output Folder with Git Integration
I'm assuming you want the published files in Git, and not the actual output folder which is updated anytime you build a target. All you really need to do is set your publish destination using the destination file in Flare, apply that destination to your target/s, and then add that publish destination to Git. If you need these files to live in the same repo as the source files, I would suggest setting the publish destination to be within the same root folder as your source files. Keep in mind that this will require working with Git outside of the Flare interface, either in Bash or in a third party GUI.
If you actually want your output folder in Git (which would be a disaster if you have more than one person working in Flare), you just need to remove that folder from the ignore file.
If you actually want your output folder in Git (which would be a disaster if you have more than one person working in Flare), you just need to remove that folder from the ignore file.
Chris Jones
Product Content Manager - TEAM Software
Product Content Manager - TEAM Software
Re: Including Output Folder with Git Integration
Thank you chrisj! Will be using destinations to get this to work--just want the files in the Git repo.
-
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Including Output Folder with Git Integration
Makes sense, but is still not the best option. Might want to look into the build license for Flare and include command line builds for help into the build process. Keeping and updating the compiled help in source control is rather ugly....no judgement cast, I am in the same boat and that is current the only option.nicaeonic wrote:Thank you, RamonS! I'm looking to host the output files alongside the sources on our server -- they'll be linked to from elsewhere (using iframes). I hope that makes sense!
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
Re: Including Output Folder with Git Integration
I could be confused on the desired outcome here, but you could still have a repo for tracking both source and published files AND run your builds in command line. It definitely gets messy if you have multiple people publishing content, but if the publishing pipeline is controlled through pull requests or just simply always done from the same machine (virtual or otherwise, with or without a build license) with a log file, then it wouldn't necessarily be ugly. For example, if I had this requirement, I would publish files locally, in the same root as my source files, and then push the changes to my remote. Doing so would actually allow you to track multiple versions of multiple targets, rather than tracking only the source files. And if I had the time of a developer, perhaps setting the command line build to fire with an approved pull request at the time of merge.RamonS wrote:Makes sense, but is still not the best option. Might want to look into the build license for Flare and include command line builds for help into the build process. Keeping and updating the compiled help in source control is rather ugly....no judgement cast, I am in the same boat and that is current the only option.nicaeonic wrote:Thank you, RamonS! I'm looking to host the output files alongside the sources on our server -- they'll be linked to from elsewhere (using iframes). I hope that makes sense!
Again, this becomes very complicated if you have multiple people/machines publishing. Of course, even without this situation having multiple people publish is problematic.
Chris Jones
Product Content Manager - TEAM Software
Product Content Manager - TEAM Software
-
- Senior Propellus Maximus
- Posts: 4293
- Joined: Thu Feb 02, 2006 9:29 am
- Location: The Electric City
Re: Including Output Folder with Git Integration
Use labels and branches on the sources to track different versions. In my case the build system runs dozens of agents across several servers. There is no telling on which system the build will take place and adding a compiler with license to all of them just because one out of a hundred or so projects needs it is financially and administratively not viable. It would be different if builds took place on one dedicated box.
You can version builds as well. If there really is a need to compile help that was released using a specific set of settings and target from three years ago then find that build definition and run it. If the source doesn't change then the better option is to compile the final output, package it all up into a compressed archive, and drop it on storage outside of the source control system.
You can version builds as well. If there really is a need to compile help that was released using a specific set of settings and target from three years ago then find that build definition and run it. If the source doesn't change then the better option is to compile the final output, package it all up into a compressed archive, and drop it on storage outside of the source control system.
New Book: Creating user-friendly Online Help
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U
Paperback http://www.amazon.com/dp/1449952038/ or https://www.createspace.com/3416509
eBook http://www.amazon.com/dp/B005XB9E3U