Can we elegantly control which directories trigger a lein auto cycle?
I might want a test run triggered whenever a resource file changes, or when a file under a custom source path or a under a :java-source-paths changes, and so on. Even trigger a cycle when the project file changes.
Last I checked I think there was no lead towards this, in the sample project file contained in the leiningen source. Since I like leiningen so much, I thought I would ask.
Related
We have a workflow that runs whenever a tag with a specific format is pushed to the main repository. Originally, the displayed name is consistent with the name: entry at the beginning of the workflow file, but this is no longer the case.
Before this change, we had a separate repository with a cron workflow that ran a python script to push the tag to the main repository, which triggers the workflow there.
We recently moved to using a workflow from the main repository to push the tag, and this is when the different workflow display name changed. There are some differences between the two triggering workflows. The old trigger ran a python script which presumably pushed the tags "from" the script. The new trigger explicitly calls git push --tags from the workflow file itself.
I believe the move to the new trigger is why the display name is changed, but I cannot be certain.
I'm using the GCE library in Go, along with go modules.
I'm finding that, while it happily compiles and runs unit tests, it's not resolving those types (e.g. compute.Instance) in the Goland IDE. I'm using 2020.2.
I first added this dependency by hand-coding (adding "google.golang.org/api/compute/v1" to my imports, and letting the module handler load whatever it needs). It added google.golang.org/api v0.50.0 to my go.mod file.
I've tried the old "Invalidate and Restart" approach, and it didn't do anything. I have another project where a different version of that module happens to be loaded, and it works fine on that one.
I've even tried a more nuclear version (Invalidate (no restart), close project, close IDE, delete the .idea directory, and delete the contents of ~/.cache/JetBrains). Still no dice.
FWIW my go module's version is go 1.15
You can navigate to the package sources by pressing Command/CTRL+Click on the import statement (or via External Libraries menu in Project View) and find compute-gen.go file and size limit warning. The IDE behaves as expected.
As a workaround, you can invoke Help | Edit Custom Properties... and add the following line idea.max.intellisense.filesize=8500000 (depends on the original file size), restart GoLand. Please, keep in mind that the IDE can be slow when dealing with large files even if they are not open in the editor.
You can read more about the idea.properties file here.
I opened my project on another computer, and the files where I'd been using a file watcher were expanded, like before they used to be nested like home.scss is now after I run the watcher once on that file.
Is there a way to automatically make all the files be nested?
Because when adding new files and folder with git, it would be quite troublesome to go into each and every file in order to make them become nested.
Like I have some minified JavaScript files that used to be nested, but now is expanded for some reason.
Hope you understand. Thank you.
Edit: Nested***
Is there a way to automatically make all the files go under a caret like that?
Unfortunately not. Such nesting information (to "go under a caret" as you are saying) is taken from "Output path to refresh" field of the corresponding File Watcher.
You have to run file watcher for such files at least once in order to see files nested like you have it on your another computer.
Here is how you can run File Watchers manually without the need to modify those files (so no extra history will appear in your git (or whatever VCS you may be using there)).
https://stackoverflow.com/a/20012655/783119
P.S.
In PhpStorm 2016.3 (the next version that will be released in 1.5-2 months or so) such nesting will be done automatically (the most common combinations) so there will be no need to have File Watchers for providing such info.
If you wish -- you can try EAP build right now (EAP means Early Access Program .. which is sort of Alpha/Beta builds (simply speaking).. and therefore some bugs for new functionality might be present and performance may not be optimal).
So the problem is that all developers need different settings for their local testing, but the settings file is part of the project (unlike the nbproject folder for example that we all ignore). I know about .htignore, but the filter only applies to files that are not part of the project.
If I forget the file, then this removes it from the "global" repository, where we have a "holder" version of the settings file.
Right now we just don't commit that file, but every now and then somebody forgets and pushes his own settings, which then are synced back to other developers and it's a constant pain. We just want to "automatically" not push that file. Is there a solution to this? Are we doing something wrong?
You could add a precommit hook that gives an error every time you try to commit this particular file.
To handle the case of developers that forget to setup such a hook, you can also add a serverside hook that will reject their push.
I am writing a WIX installer and I have a following requirement:
During installation, I need to pass an absolute path to a file (lets call it A) included in my installer to a COM component, which already exists on the hard drive and is a part of another program. I have already written an appropriate Custom Action which expects a path to the file A. I don't want to include A as a file installed in the Program Files folder and removed during the uninstallation process. Instead, I would like to put A only temporary on the hard drive, call my Custom Action which will cause the COM component to use the content of A, and then remove A from disk. Is there an easy way to accomplish this goal?
I have tried to utilize the Binary Table and store A there, however I don't know how to reference A using absolute path. I know I could put A outside of MSI file but I would like to keep every file installer needs in a single MSI.
Any help would be appreciated.
Deleting a file that MSI installed means that MSI will consider it "broken" and try to auto-repair it if called on to do so. That happens automatically in several cases (e.g., advertised shortcuts and COM registration) so I'd recommend against it. Leave the file there instead -- it's done its job and there's no harm in leaving it there.
I would take this approach.
Install the file "A" into any directory. Run your custom action needed to update the COM component. Then run another custom action or modify the currently written one to remove the file after it is no longer in use. This would leave no trace of the file "A" and if you schedule the custom action to only run during the install you won't have to worry about it on uninstall.