Initial version

[keturiosakys]

This PR creates a first version of a GitHub action that syncs the committed Fiberplane templates in a repo with your Fiberplane workspace.

The action requires at least the following inputs:

• Fiberplane auth token (created with the CLI fp tokens create)
• Workspace ID

The basic features are:

• it watches a specified folder (default: .fiberplane/templates) for new/changed *.jsonnet files
• it checks with the Fiberplane API if the templates already exist
• for those that already exists it runs an fp update command, for those that don't - fp create

Some basic assumptions:

• filenames are source of truth: they are the main item used for identifying templates between the git repo and the Fiberplane workspace
• no deletion (yet): the workflow will not delete templates in your workspace if you delete them from your repo
• no triggers: you can't use the action to add template triggers (webhook endpoints)

[hatchan]

I was thinking, maybe we should make the default without a . prefix. So something like fiberplane/templates/

To me a hidden directory is something that is secondary to the repo. For example having your own code is the primary use case of a application repo, but it might also contain a .github directory containing workflows. In the case of this action it will be run on a infrastructure like repo, where its main purpose is to store the templates.

[keturiosakys]

I don't entirely agree here. I was actually thinking that the primary way this would be used would be per team / per project basis (kinda like hooks or workflows). Teams and/or projects might want to have project-specific templates attached in which case they become like a workflow associated with the repository code. Hence the .fiberplane/ prefix

[hatchan]

I don't entirely agree here. I was actually thinking that the primary way this would be used would be per team / per project basis (kinda like hooks or workflows). Teams and/or projects might want to have project-specific templates attached in which case they become like a workflow associated with the repository code. Hence the .fiberplane/ prefix

This kinda goes against what is planned and what you mentioned earlier, that if a template is not defined in the directory then it should be deleted. Ie. the directory should match the templates that are created 1to1. If the idea is to have this in multiple directories than that workflow is not possible.

[keturiosakys]

yeah that's a good point. I'm personally not yet entirely settled how the delete workflow should work but this is a good gotcha to keep in mind when we're discussing it