Is it possible to optionally load a file like "WORKSPACE.user.bazel" from my main "WORKSPACE.bazel" file but only if that file exists?
I'd like to override certain dependencies during development only and not check in the WORKSPACE.user.bazel file.
--override_repository seems to do the job. See also this.
Related
please take a look at the bin-win target in my repository here:
https://github.com/thinlizzy/bazelexample/blob/master/demo/BUILD#L28
it seems to be properly packing the executable inside a file named bin-win.tar.gz, but I still have some questions:
1- in my machine, the file is being generated at this directory:
C:\Users\John\AppData\Local\Temp_bazel_John\aS4O8v3V\execroot__main__\bazel-out\x64_windows-fastbuild\bin\demo
which makes finding the tar.gz file a cumbersome task.
The question is how can I make my bin-win target to move the file from there to a "better location"? (perhaps defined by an environment variable or a cmd line parameter/flag)
2- how can I include more files with my executable? My actual use case is I want to supply data files and some DLLs together with the executable. Should I use a filegroup() rule and refer its name in the "srcs" attribute as well?
2a- for the DLLs, is there a way to make a filegroup() rule to interpret environment variables? (e.g: the directories of the DLLs)
Thanks!
Look for the bazel-bin and bazel-genfiles directories in your workspace. These are actually junctions (directory symlinks) that Bazel updates after every build. If you bazel build //:demo, you can access its output as bazel-bin\demo.
(a) You can also set TMP and TEMP in your environment to point to e.g. c:\tmp. Bazel will pick those up instead of C:\Users\John\AppData\Local\Temp, so the full path for the output directory (that bazel-bin points to) will be c:\tmp\aS4O8v3V\execroot\__main__\bazel-out\x64_windows-fastbuild\bin.
(b) Or you can pass the --output_user_root startup flag, e.g. bazel--output_user_root=c:\tmp build //:demo. That will have the same effect as (a).
There's currently no way to get rid of the _bazel_John\aS4O8v3V\execroot part of the path.
Yes, I think you need to put those files in pkg_tar.srcs. Whether you use a filegroup() rule is irrelevant; filegroup just lets you group files together, so you can refer to the group by name, which is useful when you need to refer to the same files in multiple rules.
2.a. I don't think so.
I would like to add this to my .bazelrc, but the $(whoami) doesn't expand like if it was in a shell.
startup --output_user_root=/tmp/bazel/out/$(whoami)
It produces the literal result:
/tmp/bazel/out/$(whoami)/faedb999bdce730c9c495251de1ca1a4/execroot/__main__/bazel-out/
Is there any way to do what I want: adding a name/hash to the option in the .bashrc file?
Edit: what I really want is to set the outputRoot to /tmp/bazel/out without using an environment variable and to let bazel create it's user and workspace hash directories there.
You can run Bazel from a wrapper script. In fact, that's exactly what the bazel binary is (at least on Linux): it's a wrapper script that calls bazel-real. You can edit this wrapper script if you like, or rename it to bazel.sh and write your own wrapper.
/usr/bin/bazel is a script which looks for //tools/bazel, and if it exists, calls it. Otherwise, it calls bazel-real. This lets you check Bazel into your repo, or otherwise modify how it gets called. We use that to download a specific version of bazel, extract it, and then call it.
I would recommend creating //tools/bazel, and having that do your modification. It can then either call a versioned version of bazel, or call bazel-real. That keeps your modifications local to your repo rather than global.
There are some properties that I have in the default generated application.yml file in Grails 3. Take for example this property
test:
network:
path: '/home/cool/testing_data'
Now, the part that I want to do is change this property when I invoke the build script, so that it is different for the various OS that it might be executed on. I.e: On windows, that path should be 'E:/shared/testing_data', and on solaris, something different.
Using this post here, I can conclude that I can identify which OS I am currently on, so that I can potentially make some changes. Ex:
import org.apache.tools.ant.taskdefs.condition.Os
task checkWin() << {
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
// it is windows, lets change the path to not be linux like
}
}
So my question is, using gradle or any other means as necessary, can I change the properties in application.yml file to accommodate the different OS systems that the application might be deployed on? I am considering reading the application.yml file line by line and doing a string replacement, but I will resort to this only if there are no cleaner solutions.
Maybe am I using the wrong tool to solve this problem as is, so a good question to ask is, is there an easier way that I am missing here, possibly a similar approach to different "environments" like :test, dev, prod, for operating systems, already built into the core functionality of grails that I can re-use?
Just create application.groovy file in the same folder as application.yml is. In groovy file you can use any script to set value of properties.
For example add this line to application.groovy file (also remove option from yml):
test.network.path = Os.isFamily(Os.FAMILY_WINDOWS) ? 'd:\something' : '/home/something'
I'd like to store properties in a database tables and have defaults for those properties set in Config.groovy. For example, I want to put a default email address into Config.groovy:
app.send.report.to = 'me#example.com'
and then be able to override this in a database table (key, value columns...).
Is there a plugin (or functionality inside grails) to do this?
There is Dynamic Config Plugin.
It stores config property in ConfigProperty domain and merges properties from Config.groovy and from database using:
grailsApplication.config.merge(configObject)
You may want to look at the plugin source code. If plugin does not work for you, you can implement something similar to this.
This approach is useful when you have UI for editing config properties.
Grails does not have functionality that I'm aware of to override configuration values from a database, but it shouldn't be that difficult to do. In your Config.groovy you could put the defaults, and then as part of your bootstrap process, you could generate a temporary config file that has the values from the database (a simple query and iteration over the results could be used to generate that temp file). Include that temp file as one of your grails config locations, and it will override any values that are in the Config.groovy
If your goal is to have a shared configuration file that is used by multiple grails apps, you might also look into using something like Zookeeper to manage the shared configuration, but that may be a bit overkill for a single config file.
Not quite what you're asking for, but depending on what you want to achieve the External Configuration Reload plugin might be of use. It helps you to override default properties (in runtime), but not by using the DB.
When my Grails application starts, I build up a data structure from a CSV file downloaded from a remote URL. If the file is not accessible, I'd like to fall back to a local copy. Currently processing the file in the service layer, initiated using a Quartz job.
What is the best practice, using Groovy, for reading a local resource in Grails?
Where should I stash the file?
How do I safely and properly read the file?
General-case answers will be very acceptable.
I think the best way to deal with this is to store the file's location in an externalized configuration file.
So, you'd determine a standardized location (such as /etc/myappname/CSVFileConfig.groovy), or pass the config file path in using an environment variable or something similar. See Externalized Configuration for examples.
Then you can simply add the actual path to the local file to that extenal config, like so:
// CSVFileConfig.groovy
my.custom.csv.path = ...
Finally, access it using normal config operations:
// in your Quartz job
def path = grailsApplication.config.my?.custom?.csv?.path
if(!path) {
// no file to load
} else {
// load file
}
As far as reading the file, what are your primary concerns? If you are using a CSV library, such as OpenCSV (used in most of the Grails libraries for CSV parsing), it will handle the opening and parsing of the file.
For security issues beyond that, I'm not sure how to handle them in a generic way. It will depend on your specific scenario. I think the one coming from a URL has a higher risk factor.