Which folders would need to be tracked to capture tags, images and gateway configurations into a GIT repository?
It would be awesome if it was possible to automatically migrate binary files from projects pulled from GIT repositories, rather than having to do a gateway restore.
You'll probably have to wait a while for complete guides to become available.
For now, I'll mention that files created in the external "resource collection" (also known as mode or just collection; roughly analogous to a "project") are guaranteed to go untouched by Ignition and will be treated as immutable. If you want to preconfigure/deploy gateways from source control, that's going to be your preferred avenue - essentially, duplicate the nested folder structure from data/config/resources/core/
and manually repeat it in data/config/resources/external/
for whatever resources you care about.
'Gateway configurations' is too broad - basically everything in the gateway is now captured in independent resource types, so you have to choose how selective (or not) you want to be when storing configuration to VCS. Images, for instance, are stored in data/config/resources/core/ignition/images.
Thanks for the quick answer! Definitely nice to see all the resources in JSON format
If we were happy tracking all the changes the gateway makes in a basic dev/production server environment, would it be safe to push/pull directly to/from the 'core' folder, or would this risk corrupting the gateway in some instances?
The gateway doesn't scan for changes to the resources on disk in 8.3, so you'll have to update your deployment automation/process to (for now) hit the scan config collection endpoint on our new REST API. Other than that, the only 'risk' is having written out files/folders that don't make sense to the gateway and cause issues.
Are these endpoints publicly documented anywhere yet? Currently mid-rebuild on Flint for 8.3, and looking to add support for the native project scan endpoint.
Yeah, the plan is still a "complementary" scripting API - it won't be a 1:1 copy of the REST API but will be able to express ~all the same capabilities. Timeline is no earlier than 8.3.1.