{"action":"created","issue":{"url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/issues/2058","labels_url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/issues/2058/labels{/name}","comments_url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/issues/2058/comments","events_url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/issues/2058/events","html_url":"https://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/2058","id":119750474,"number":2058,"title":"Apply test file build tags to test run/debug configurations","user":{"login":"mmindenhall","id":1106269,"avatar_url":"https://avatars.githubusercontent.com/u/1106269?v=3","gravatar_id":"","url":"https://api.github.com/users/mmindenhall","html_url":"https://github.com/mmindenhall","followers_url":"https://api.github.com/users/mmindenhall/followers","following_url":"https://api.github.com/users/mmindenhall/following{/other_user}","gists_url":"https://api.github.com/users/mmindenhall/gists{/gist_id}","starred_url":"https://api.github.com/users/mmindenhall/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mmindenhall/subscriptions","organizations_url":"https://api.github.com/users/mmindenhall/orgs","repos_url":"https://api.github.com/users/mmindenhall/repos","events_url":"https://api.github.com/users/mmindenhall/events{/privacy}","received_events_url":"https://api.github.com/users/mmindenhall/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/milestones/16","html_url":"https://github.com/go-lang-plugin-org/go-lang-idea-plugin/milestones/1.0%20maybe?","labels_url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/milestones/16/labels","id":976865,"number":16,"title":"1.0 maybe?","description":"This is a milestone to help decide which issues should be done in 1.0 initial release and which should go in the next versions.","creator":{"login":"dlsniper","id":607868,"avatar_url":"https://avatars.githubusercontent.com/u/607868?v=3","gravatar_id":"","url":"https://api.github.com/users/dlsniper","html_url":"https://github.com/dlsniper","followers_url":"https://api.github.com/users/dlsniper/followers","following_url":"https://api.github.com/users/dlsniper/following{/other_user}","gists_url":"https://api.github.com/users/dlsniper/gists{/gist_id}","starred_url":"https://api.github.com/users/dlsniper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dlsniper/subscriptions","organizations_url":"https://api.github.com/users/dlsniper/orgs","repos_url":"https://api.github.com/users/dlsniper/repos","events_url":"https://api.github.com/users/dlsniper/events{/privacy}","received_events_url":"https://api.github.com/users/dlsniper/received_events","type":"User","site_admin":false},"open_issues":42,"closed_issues":0,"state":"open","created_at":"2015-02-12T14:28:40Z","updated_at":"2015-12-01T16:16:42Z","due_on":null,"closed_at":null},"comments":7,"created_at":"2015-12-01T16:10:42Z","updated_at":"2015-12-02T17:48:53Z","closed_at":null,"body":"Given a `_test.go` file containing a single build tag (e.g., `integration` to separate unit tests from integration tests), when any action is performed that creates a new \"Go Test\" run/debug configuration (for individual test or entire file), then that run/debug configuration should specify the build tag.\r\n\r\nWith the current behavior, if I'm within a test file and I use ctrl+shift+r to run a test or all tests within the file, the build tag is not applied, and the run/debug config that is automatically created does not run any tests.\r\n\r\nThere may be occasional cases where a `_test.go` file uses multiple build tags.  In these cases, if it's clear that there's only a single combination of tags that would permit the test(s) to execute, those tags should be applied.  For example, consider a test file with the following build tags:\r\n\r\n```go\r\n// +build integration,foo,!bar\r\n```\r\n\r\nThis is equivalent to (`integration` AND `foo` AND (NOT `bar`)), so the IDE should apply both `integration` and `foo`.\r\n\r\nIf the build tags can't be resolved to a single valid combination, the current behavior should apply, and the run/debug configuration should be created, and the user can manually specify the tags."},"comment":{"url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/issues/comments/161378619","html_url":"https://github.com/go-lang-plugin-org/go-lang-idea-plugin/issues/2058#issuecomment-161378619","issue_url":"https://api.github.com/repos/go-lang-plugin-org/go-lang-idea-plugin/issues/2058","id":161378619,"user":{"login":"mmindenhall","id":1106269,"avatar_url":"https://avatars.githubusercontent.com/u/1106269?v=3","gravatar_id":"","url":"https://api.github.com/users/mmindenhall","html_url":"https://github.com/mmindenhall","followers_url":"https://api.github.com/users/mmindenhall/followers","following_url":"https://api.github.com/users/mmindenhall/following{/other_user}","gists_url":"https://api.github.com/users/mmindenhall/gists{/gist_id}","starred_url":"https://api.github.com/users/mmindenhall/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mmindenhall/subscriptions","organizations_url":"https://api.github.com/users/mmindenhall/orgs","repos_url":"https://api.github.com/users/mmindenhall/repos","events_url":"https://api.github.com/users/mmindenhall/events{/privacy}","received_events_url":"https://api.github.com/users/mmindenhall/received_events","type":"User","site_admin":false},"created_at":"2015-12-02T17:48:52Z","updated_at":"2015-12-02T17:48:52Z","body":"In general, I'd like to ask you as the primary authors of this plugin to be more open minded about valid use cases.  I appreciate the push back and discussion about how best to support various use cases within the plugin, but I feel like the previous comment is dismissive of a perfectly valid use case.  I should mention that my entire team and I are paying JetBrains customers, so I can't help having the same high expectations of this plugin as I have for any \"official\" plugin (e.g., Scala).  :smile:\r\n`</soapbox>`\r\n\r\nSo two things:\r\n\r\n1.  In my previous comment, I suggested making the `Custom build tags` support a checkbox toggle within the run/debug configuration.  That way it doesn't affect anyone who doesn't need it.\r\n1.  For the case you mentioned above:\r\n\r\n    > Custom build tags: integration, my_local_machine\r\n    > Build tags in file: // +build (NOT integration)\r\n    > What's the expected result?\r\n\r\n    I don't think this is a valid case, as `integration` would be a file tag specific to tests, rather than a custom build tag.  But for the sake of argument, let's say that we have custom build tags of `foo,bar` and file build tag of `// +build !foo`.  IMHO, the expected result is that the initial cut at this feature just merges the tags, and in this case it would be invalid:  `-tags \"foo,bar,!foo\"`, which would presumably cause a runtime error, and the user would need to figure out how to proceed.  Maybe it never happens, or it does but isn't a big enough pain point for someone to complain.  Or maybe it bothers someone enough to file an issue, describe the problem and how it can be fixed, and this feature can improve.\r\n\r\n> 1.   How to merge tags from file and tags that were manually set in Go tool arguments in defaults of Go Test run configuration? E.g. // +build (NOT my_local_machine) in file and -tags my_local_machine in defaults.\r\n> 1.   Should this work only for creating test on function or file? Do you have any thoughts how it could work while running on a package or a directory (ctrl+shift+r on directory)?\r\n\r\nRegarding *#*1, same as above.  AND together (`-tags \"my_local_machine,!my_local_machine\"`), let an error happen, and let the user figure out how to proceed.\r\n\r\nRegarding *#*2, this seems more tricky, as there could be multiple files in the package with conflicting build tags.  But this case actually makes even more sense for supporting the `Custom build tags`, as it makes it easy to quickly test packages with specific tags applied.  In my case, I could set `profile_small`, test entire packages with that profile (repeating with other profile tags).  But if I only wanted to run the integration tests within the package?  That requires some more thought.  I think the `integration` tag could be considered idiomatic, so maybe add more specific support for running with that tag applied?"}}