If I define a custom --config option in my .bazelrc such as
# My custom config
build:my_config --define my_setting=true
build:my_config --define my_other_setting=true
is there any way to get this to show up in "bazel help build" or some other command. Preferably with some sort of custom help text. I think this would be a nice feature for keeping track of build options. Especially, due to some projects like tensorflow, wanting to create .bazelrc configs even as an external dependency.
is there any way to get this to show up in "bazel help build" or some other command
No, unfortunately Bazel doesn't have a feature like this.
Related
given a bazel command, for example bazel build //..., is it possible to see what build command this expands to based on the bazelrc(s)?
bazelrcs are great to set default flags, like the default platform to build for setting some variables based on profiles.
They also allow for nested bazelrcs, that you can import and try-import leading to a rather complex expansion of bazel commands via bazelrcs.
To verify that the bazelrcs did indeed configure the correct things and did not override some flags accidentally, I would love to see the output of what bazel would expand a bazel command to.
Is that possible?
I tried setting --logging=0 and --logging=6 with bazel 5.3.0 but see no such output.
You can run your build using the --explain flag.
Something like
bazel build --explain explain.log //...
should produce a file explain.log where the first line contains the expanded flags.
How is it possible to access which features the package is being built with, inside the build.rs script? There is an incredibly expensive step in the script which is only needed for a particular cargo feature, but I can't see any way to access config features inside the build script.
Is there any way to read whether or not a given feature is enabled in the build.rs script?
I haven't been able to find documentation here, but was able to figure out one solution by guessing.
Cargo features are available as build features not just in the main source files, but inside the build.rs script as well. So you can use any of the standard ways to check configuration, like the cfg! and #[cfg(feature = "...")] macros, as mentioned in https://doc.rust-lang.org/reference/conditional-compilation.html and How do I use conditional compilation with `cfg` and Cargo?
Cargo sets a number of environment variables when the build scripts are run:
https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts
Including an environment variable for each feature:
CARGO_FEATURE_<name> — For each activated feature of the package being built, this environment variable will be present where <name> is the name of the feature uppercased and having - translated to _.
My runner file in my local system
My Jenkins configuration
Feature structure
As per my requirement, I have created separate features
{IndiaTransaction,CreateTransaction,BrazilTransaction,Mexico Transaction.features}
The above syntax will run all the features But I want to run specific features in my Jenkins, So how to configure it? I have tried below 2 methods it is not working, please help me to resolve
You can add a build step with Execute shell in Jenkins for the project and use the command below:
mvn test -Dcucumber.options="--tags #CreateTransaction,#BrazilTransaction"
And you can remove the tags option in cucumber runner class because the same thing you can do with -Dcucumber.options="--tags #tagName" in the command line
Please make sure you are using same tags in the feature files as well as in the command line.
Is there a list of tools that are assumed to be always in the PATH when a Bazel target runs a shell command?
This is relevant for creating isolated build environments. AFAIU (see https://github.com/NixOS/nixpkgs/pull/50765#issuecomment-440009735) by default Bazel picks up tools from /bin and /usr/bin when in strict mode.
But what can ultimately be assumed about the minimal content of those? For example, I saw awk to be used liberally. But then git as well, which sounds border-line.
I imagine the exact set might correspond to whatever Google-internal Bazel expects to find in Google's build images bin directories. At least for BUILD rules open-sourced by Google.
Is there such a definitive list? Thank you.
As far as I can tell, your assessment of the tool usage is correct, and unfortunately I'm not aware of such a list.
There should be one, and Bazel should treat the shell as a toolchain. Alas nobody is working on that at the moment. See https://github.com/bazelbuild/bazel/issues/5265.
I am trying to set the build name of a Jenkins build only on a successful build. Any failure, whether in building or testing, should use the 'default' (build number) instead.
I can't find any mention of this in the documentation or online. Is this possible?
It is pretty simple to do with Groovy Postbuild: https://wiki.jenkins-ci.org/display/JENKINS/Groovy+Postbuild+Plugin
You have some nice examples there too. So just check result and then set the:
manager.build.result
As they do in Example 3
In the post build operation you can run a "set of scripts" - there you can select any way to do so, set a description, run system groovy or groovy script to change the name or any other method of your choosing - you can add many build steps to help you do so. wrap it around a conditional statement and run it only when build is successful.
Good luck!