-
Notifications
You must be signed in to change notification settings - Fork 0
allow loading .goplicate.yaml targets from template repository #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @skurfuerst! I'm awfully sorry that it took me 28 days to respond to you (I need to fix my notifications). First, every suggestion is welcome at this stage as it's an early-stage project with many bright possible evolutions. To see if I understand you correctly, syncing/importing a target from a remote template repository would mean that after the sync, goplicate would run on these targets, but in order for the target to be changed in a meaningful way, it has to contain the annotations in order to update the relevant blocks in the target files, right? So, I'm not sure how it will work exactly. Can you elaborate with an example use case? 🤩 |
Hey @ilaif , no worries :) You are right, the target needs to contain the annotations, if it exists. I imagine the following scenario:
=> Right now, as far as I understand it, this won't work because the .goplicate.yaml needs to contain the new files for that. That's why I thought as a workaround, of syncing the .goplicate.yaml itself using goplicate -> so on first run, you would update the .goplicate.yaml, and on second run, it would create the new files. Does the scenario make sense to you, or not? :) All the best, |
@skurfuerst I really like that! I think the core functionality that is missing today is the syncing of a whole file. I'd be happy for you to open a PR and we'll push it together into a fast deployment at your company. So, feel free to open a PR (draft or not), and let's get this rolling 🤘🏼 We can also start discussing the new API this requires as I feel this will require some thought to scale way with future additions. I'd also appreciate any honest feedback about the current codebase and what can be improved 🙏🏼 |
Awesome :) I will check it out and prepare a PR. It might take a few weeks until I get back to you, as I currently have lots of open todos on my table. All the best, |
Hi @skurfuerst, I wanted to share that we have released v0.2.0 that adds support for remote git URLs (instead of assuming your projects are already checked out locally). This mainly helps with the automation of the whole flow and reduces errors since the fresh clone is always clean 🧹 Let me know if you already had some time to take a look at your use case 🙏🏼 |
Hi @skurfuerst, Basically, you can now add a I'm reminding you that all source paths can now be synced from a repository, which makes it stateless and clean! Please let me know if that works for your use case 🙏🏼 🎉 |
Awesome, really cool! Thanks so much :):) I will test it in the upcoming days and give feedback :) All the best, |
Reopening until @skurfuerst confirms this works 🙏🏼 |
Sorry, did not get around doing this over the holidays - a happy new year to you 😊 I will test it soon. All the best, |
Happy new year, @skurfuerst ! |
Hey,
great project - I'd really love to use this in our company and I have been looking for such a thing for a long time :)
One question: In our use case, it would be very helpful to be able to import a set of targets from a remote template repository - or alternatively, sync the .goplicate.yaml file using the tool itself!? (or is this inception? :D )
Would you be open for such a change or have some specific ideas about it? if yes, I could also prepare a PR.
All the best,
Sebastian
The text was updated successfully, but these errors were encountered: