I'd like to change the scan properties on only one project for our build server. I've found tons of references for what to change in the various fortify ".properties" files, but I don't want to make any changes that will be universal.
Is it possible to either define these on the command line or, even better, specify a specific .properties file to use only for the current scan?
Note, this has to be via the command line.
Yes, for any property that you want to change put it in the appropriate command line (translate vs scan) in the following format:
-D<property key>=<property value>
for example
sourceanalyzer -b mybuild -Dcom.fortify.sca.fileextensions.sql=PLSQL *.sql
Related
I want to create some "build traceability" functionality, and include the actual bazel command that was run to produce one of my build artifacts. So if the user did this:
bazel run //foo/bar:baz --config=blah
I want to actually get the string "bazel run //foo/bar:baz --config=blah" and write that to a file during the build. Is this possible?
Stamping is the "correct" way to get information like that into a Bazel build. Note the implications around caching though. You could also just write a wrapper script that puts the command line into a file or environment variable. Details of each approach below.
I can think of three ways to get the information you want via stamping, each with differing tradeoffs.
First way: Hijack --embed_label. This shows up in the BUILD_EMBED_LABEL stamping key. You'd add a line like build:blah --embed_label blah in your .bazelrc. This is easy, but that label is often used for things like release_50, which you might want to preserve.
Second way: hijack the hostname or username. These show up in the BUILD_HOST and BUILD_USER stamping keys. On Linux, you can write a shell script at tools/bazel which will automatically be used to wrap bazel invocations. In that shell script, you can use unshare --uts --map-root-user, which will work if the machine is set up to enable bazel's sandboxing. Inside that new namespace, you can easily change the hostname and then exec the real bazel binary, like the default /usr/bin/bazel shell script does. That shell script has full access to the command line, so it can encode any information you want.
Third way: put it into an environment variable and have a custom --workspace_status_command that extracts it into a stamping key. Add a line like build:blah --action_env=MY_BUILD_STYLE=blah to your .bazelrc, and then do echo STABLE_MY_BUILD_STYLE ${MY_BUILD_STYLE} in your workspace status script. If you want the full command line, you could have a tools/bazel wrapper script put that into an environment variable, and then use build --action_env=MY_BUILD_STYLE to preserve the value and pass it to all the actions.
Once you pick a stamping key to use, src/test/shell/integration/stamping_test.sh in the Bazel source tree is a good example of writing stamp information to a file. Something like this:
genrule(
name = "stamped",
outs = ["stamped.txt"],
cmd = "grep BUILD_EMBED_LABEL bazel-out/volatile-status.txt | cut -d ' ' -f 2 >\$#",
stamp = True,
)
If you want to do it without stamping, just write the information to a file in the source tree in a tools/bazel wrapper. You'd want to put that file in your .gitignore, of course. echo "$#" > cli_args is all it takes to dump them to a file, and then you can use that as a source file like normal in your build. This approach is simplest, but interacts the most poorly with Bazel's caching, because everything that depends on that file will be rebuilt every time with no way to control it.
I can create a label_flag in Bazel to allow command line flags to in turn be matched with a config_setting in a Bazel BUILD file.
However, I'd like to not hard-code the default value of the label_flag, and instead compute a good default based on the system when evaluating a repository_rule (or some other part of the WORKSPACE file).
The best (but awful) way I've come up with to do this is to have the default value loaded from a .bzl file that is generated using the template function on the repository_ctx.
I feel like generating a new file by doing textual substitutions probably isn't the right way to do this, but I can't find anything else. Ideas? help?
Generating a bzl file using the repository rule that inspects the host system is the only way to achieve what you need right now. So you're holding it "right" :)
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.
I am attempting to write a batch file for my developers to run that sets up workspaces. The batch file will use Plastic's command line utility, cm.exe.
When I create a workspace in the Plastic client GUI, there is a combo box that allows me to select the repository. This generates a plastic.workspace file, and a plastic.selector file that contains a reference to the selected repository.
However, when I use the command line utlity to make a workspace, I have to specify an existing selector:
cm mkwk MyWorkspace c:\MyWorkspacePath --selector=my.selector
or edit the selector when prompted:
cm mkwk MyWorkspace c:\MyWorkspacePath --selector
Ideally, I would like to be able to do something like
cm mkwk MyWorkspace c:\MyWorkspacePath MyRepository#MyServer:8888
and have the files generated the same way that they are done by the GUI.
Is there a way to do this using cm.exe, or do I have to write all the selectors beforehand?
Although it's not documented, you can issue the "mkwk" command with the "--repository" parameter. For example:
cm mkwk code c:\code --repository=code#localhost:8087
Hope it helps!
Basically, I know I can go through my control panel and modify the path variable. But, I'm wondering if there is a way to through batch programming have a temporary path included? That way it is only used during that batch file execution. I don't want to have people go in and modify their path variables just to use my batch file.
Just like any other environment variable, with SET:
SET PATH=%PATH%;c:\whatever\else
If you want to have a little safety check built in first, check to see if the new path exists first:
IF EXIST c:\whatever\else SET PATH=%PATH%;c:\whatever\else
If you want that to be local to that batch file, use setlocal:
setlocal
set PATH=...
set OTHERTHING=...
#REM Rest of your script
Read the docs carefully for setlocal/endlocal , and have a look at the other references on that site - Functions is pretty interesting too and the syntax is tricky.
The Syntax page should get you started with the basics.
There is an important detail:
set PATH="C:\linutils;C:\wingit\bin;%PATH%"
does not work, while
set PATH=C:\linutils;C:\wingit\bin;%PATH%
works. The difference is the quotes!
UPD also see the comment by venimus
That's right, but it doesn't change it permanently, but just for current command prompt.
If you wanna to change it permanently you have to use for example this:
setx ENV_VAR_NAME "DESIRED_PATH" /m
This will change it permanently and yes, you can overwrite it in another batch script.