You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when we sync files (state, config, and spec) to GitHub, we name them by the project UUID. This is a pain because the uuids are long and it is hard to identify which project.
Would there be a way to (by default) name those files project-slug.spec.yaml, project-slug.state.json , and project-slug-config.json without breaking the integration logic?
The deploy workflow could stay the same if we needed, as that’s hidden in a folder anyway and doesn’t bother anyone.
We would need to add a bit of logic only during setup to ensure that those files don’t already exist, and then append a 2 at the end of the filenames or something, but as long as we have the config_path saved on Lightning and we’ve written the config.json to point correctly to files the way we want for this repo, the names shouldn’t matter at all, right?
The text was updated successfully, but these errors were encountered:
Currently when we sync files (state, config, and spec) to GitHub, we name them by the project UUID. This is a pain because the uuids are long and it is hard to identify which project.
Would there be a way to (by default) name those files project-slug.spec.yaml, project-slug.state.json , and project-slug-config.json without breaking the integration logic?
The deploy workflow could stay the same if we needed, as that’s hidden in a folder anyway and doesn’t bother anyone.
We would need to add a bit of logic only during setup to ensure that those files don’t already exist, and then append a 2 at the end of the filenames or something, but as long as we have the config_path saved on Lightning and we’ve written the config.json to point correctly to files the way we want for this repo, the names shouldn’t matter at all, right?
The text was updated successfully, but these errors were encountered: