What Are Run Targets & How To Run Code Anywhere
Previously, when you were using GoLand, you could test and run your code only on the same machine you had the IDE installed on. You could use the FTP/SFTP Connectivity (ex. Remote Hosts Access) plugin and the Settings/Preferences | Tools | External Tools feature or the built-in Docker plugin to achieve some sort of workflow.
However, this was not convenient to use and did not have the integration level that our users expect when using our tools. That is why our team embarked on a journey to provide a better experience for these kinds of workflows.
And that’s how the Run targets feature came to be. What is it, and why do we call it such?
What are Run Targets
A target is an environment usually preconfigured by you or your IT department, capable of building or running your code.
What could be some of these targets?
- your local machine
- a Docker container
- a server with an available SSH connection
- the Windows Subsystem for Linux v2 (WSL 2, also known as WSL)
- etc.
As I mentioned earlier, you could already run/debug your code on the local machine. The Run Targets expands this concept to seamlessly run/debug your code in other targets, like those mentioned above.
Current capabilities and limitations of Run Targets
GoLand currently has two main types of Run Configurations that need to work with a Run Target: Go Build and Go Test.
What’s the difference between Run Configurations and Run Targets?
A Run Configuration is the set of arguments, environment variables, and other settings that allow the IDE to compile and run your application or tests. The Run Target feature is a new part of the Run Configuration. To learn more about Run Configurations, you can visit our dedicated Help page.
Each of these has different options, such as:
- You can build or test a file, a directory (and all subdirectories), or a package.
- You can choose to build with or without running after that.
- You can choose to run the tests, with coverage or not, profile the tests or benchmarks using the supported frameworks (standard tests/benchmarks, gocheck, or testify).
- And, finally, you can choose to run all of the above or debug them.
If this complexity is not enough, you have to add the following Go options to the list too:
- There are essentially two project models: GOPATH (to be deprecated in the future) or Go modules.
- Each of these project models can use the vendoring approach or not for managing the dependencies.
Where does this leave us in terms of scenarios, and which ones should we prioritize?
Out of all of these, any scenario that involves building on the local machine gives us the most flexibility, especially since Go can natively cross-compile to other architectures/operating systems without any problems.
When you build locally, you can pretty much do anything, run, debug, run tests, profile, and get test coverage on any supported run target: local, Docker, SSH, or WSL. There may be a few issues here and there that may show up in certain conditions.
Known issues and limitations
As with any other feature in the world of software development, Run Targets is not without some caveats.
Building on the run target changes things a bit.
Given that most users adopt Go modules in favor of GOPATH and GOPATH will eventually be deprecated by the Go team, we decided to focus on building on the run target when using Go modules support first. Based on your feedback, we’ll determine if we need to prioritize the GOPATH mode or not.
At the moment, we do not support SSH run targets from Windows, in either project model, in both local and remote building modes. We are tracking this under issue number Go-10609, and we’ll update it as soon as we make any progress in solving it.
Before I end this article, let me describe another feature of Run Targets. Once you know how to configure and use a particular target, like Docker or WSL 2, then using others will be similar. This allows you to focus on your application’s business logic rather than your run environment’s configuration management.
That’s about it for today. To sum up, Run Targets are environments under which our code will run. Thanks to this feature, GoLand can now seamlessly use Docker, SSH, or WSL 2 to run our code.
I plan to dive into each of these features individually with dedicated articles, so check back soon to learn more.
As usual, your feedback is critical for the success of features such as these. Please don’t hesitate to reach out to us with any questions or feedback you have in the comments section below, in our issue tracker, in the Gophers Slack #goland channel, or via our social media channels, such as Twitter @GoLandIDE.
Subscribe to GoLang Blog updates
