Skip to content
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

Shell scripts #384

Open
majkinetor opened this issue Sep 5, 2019 · 5 comments
Open

Shell scripts #384

majkinetor opened this issue Sep 5, 2019 · 5 comments

Comments

@majkinetor
Copy link

You should support running shell scripts as a part of migration for more complex scenarios.

@erikbra
Copy link
Member

erikbra commented Oct 13, 2019

Thank you for your suggestion. Do you have any examples of concrete use-cases where you want shell scripts to be run in a special order together with your sql scripts?

@majkinetor
Copy link
Author

majkinetor commented Oct 14, 2019

  • Create a backup before/after migration
  • Send migration metrics to metrics server
  • Create complex logic not easily achievable using SQL
  • Do some infrastructure work, for example, deploy managed DLLs onto Sql Server server which might be introduced in the migration.
  • Dynamic generation o SQL scripts, for example, obtain latest data via some other mean, for example REST service to obtain latest currencies and seed them into the database.

@satsandco
Copy link

I think this would be a great feature.
We already love RH for managing the deployment of our db scripts into numerous environments.
We also use a lot of scripts to manage our infrastructure in Azure.
This infrastructure can change and evolve over time and we may need to sometimes apply new (1 time) scripts.

@erikbra
Copy link
Member

erikbra commented Oct 4, 2020

I'm not totally sure these kinds of script should be inside the RoundhousE world, though. Why would you need the RH semantics for such scripts? Couldn't this be another part of the release? I'm open to being convinced otherwise, by all means, but it is dependent on someone taking ownership of this feature, as my time is very limited, I'm afraid.

Do you have any suggestions as to how the feature should work? Should there be "drivers" for each external script type (e.g. PowerShell, bash, cmd, python, etc), should they all be dependent on the enviroment? Which context should they run in?

@majkinetor
Copy link
Author

majkinetor commented Oct 4, 2020

I would make this as simple as possible.

PowerShell only (via it you can do all things you mention) with exactly the same triggers as with sql and yet are done only in context of migrations.

Why would you need the RH semantics for such scripts?

I already provided the reasons in the comment above. Many things are not possible with sql only.

as my time is very limited, I'm afraid.

Sure, in FOSS world this is absolutely normal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants