A simple and lightweight GUI tool for automation of.. well, of automation.
- Have a lot of scripts that you run daily?
- Wish there was something nicer than
script1.sh && script2.sh
to run scripts in a sequence? - Getting a combinatorial explosion of the number of batch files to run all the common script combinations?
You are in the right place.
- No more time wasted because you missed when one script finished and didn't start the next script right away.
- No more focus lost on maintaining the running scripts.
- No more figuring out which script failed, or scrolling up to see the log of a specific script in a batch.
Now you can schedule the exact combination of scripts to run in just a few clicks. You can go for lunch or continue working on something else, knowing that the work will be done even without your active involvement.
scripter is not a tool that forces you to build your workflow around it, it is just a complimentary tool in your toolbox. Run your scripts as usual, and run them with scripter when you want to run many scripts sequentially. See how it works for you, and check out how you can configure scripter to satisfy your needs.
- Queue the execution of the specific chain of scripts that you need right now, just in a few clicks
- Specify arguments, retry count, and some other parameters if needed
- Configure once what scripts you can run. No need to edit scripts or configs manually
- See the state of the execution, or open the complete logs to see the details
- Save often-used script combinations into presets, run a preset in just two clicks
- Operating system: Windows, Linux or Mac
- Download a version from the releases page and unzip it
- Run scripter, press the "Edit" button, and add the scripts you want to run through it
- Prepare scripter to be run from the appropriate working directory if needed in the way that suits your workflow:
- either add the tool location to the PATH environment variable
- or make an alias/script to run it from the terminal
- or create a Windows shortcut to run it in the desired directory
- or provide
--work-path your_path
to the executable when running
- Clone the repository
- Build using
cargo build --release
- Run scripter, press the "Edit" button, and add the scripts you want to run through it
- Run the scripter executable the way you configured it before
- Add the scripts you want to run to the queue and specify their arguments if needed
- Start the execution
--config-path <path>
- path to the JSON file with the configuration of scripter that should be used for this instance--work_path <path>
- path to the working directory that will be used to execute the scripts--logs-path <path>
- path to the directory where logs will be stored (requires write access)--env <key> <value>
- specify an environment variable that will be set to every script (can have multiple--env
arguments)--title <title>
- specify an additional line of title that goes under the path in the Execution tab
I wanted to keep the tool simple but at the same time useful for different situations. Every use case is a bit special, and here are some tricks you can do to achieve some desired behaviors (please share if you still lack some configuration options).
- You can run console commands from scripter as well, for example, you can set "git" as the "command" and be able to schedule any git command by changing the arguments before running it.
- You can make a script run even when some other script fails. Set the "Ignore previous failures" checkbox when configuring the script or before running it.
This allows you to set up "notification" scripts that play a sound, show a message, or send an email to you when the list is finished, regardless of the outcome of the run. - You can set up a script to try again if it fails. Set a positive value to "Retry count" when configuring the script or before running it.
This allows to more reliably run scripts that depend on a stable internet connection. It would be a waste of time to run scripts to prepare freshly built branches in the evening, and then find in the morning that "git pull" failed because the network was unstable. - You can specify commands relative to the scripter executable in the config, setting the "path_relative_to_scripter" parameter to true.
This allows bundling scripter with the scripts to share with other developers and allows everyone who gets your tools to have the same experience regardless of their local setup. - As arguments to scripter you can provide both the path to the configuration file and the path to the directory where logs will be stored.
This makes it possible to have multiple lists of available scripts or keep a split between bin/etc/temp directories. - You can specify environment variables for scripts when you start scripter by providing
--env
arguments
This makes it possible to run the same scripts in different configurations (e.g. compiling in Debug/Release) and fine-tune the level of configurability. Using--title
argument also allows you to show the information about the current context of the execution to the user of your scripts. - You can specify a path for a "local" config, splitting the config into two parts: "shared" and "local", that can be edited independently.
This allows users of your scripts to add their own scripts without affecting the config you ship to them, and without ever needing to care about how they update their script definitions. - You can add
.scripter_config.json
to your project folder, then when scripter is being run from that directory it will use this file as the current config.
This allows to use scripter with differently configured projects without the need to provide the path to the correct config manually
This project is licensed under the MIT license.