0.8.9

Small change to allow show to support same ownership options as wait.

What's Changed

• include owner in show command by @xansec in #20

Full Changelog: 0.8.8...0.8.9

0.8.8

Fixed another bug when RUNFILES_MANIFEST was not set/present on the machine.

What's Changed

• fix path resolution by @xansec in #19

Full Changelog: 0.8.7...0.8.8

0.8.7

More robust path resolution on Windows

What's Changed

• path resolution by @xansec in #18

Full Changelog: 0.8.6...0.8.7

0.8.6

Full Changelog: 0.8.5...0.8.6

Just added back missing dependencies.

0.8.5

What's Changed

• python script support by @xansec in #16 and #17

This should remove the platform dependency between Linux and Windows execution environments. The main motivation here was to avoid symlinking on Windows which was A. Expensive and B. Could lead to missing executables when the output base differed from the Bazel working directory. Note that there is still a dependency on generating a batch script due to Windows limitations, but this simply calls a Python script which should correctly resolve the exe path regardless of platform.

Full Changelog: 0.8.4...0.8.5

0.8.4

What's Changed

Note: This is a BREAKING change!! Migration steps included.

• Previously, the mayhem_run rule was invoked with bazel build, which A. was counterintuitive and B. prevented users from running multiple times as Bazel would not kick off a run if no files were modified (because it considered it a build output). Now, mayhem_run rules are invoked with bazel run. This is accomplished using runfiles, which is now necessary to enable in .bazelrc with common --enable_runfiles.
• Previously, sarif and junit files were saved under the bazel-rules_mayhem root directory. Now, they are saved in the same directory as the target runfiles (i.e. my_target.sh.runfiles/_main)
• Added support for image_dependency for the mayhem_run rule, so that the output of a call to oci_push can be depended on prior to running Mayhem.
• Fixed a bug where owner information for the mayhem wait command could be duplicated, causing the command to fail.
• Added rules_shell and rules_cc as dependencies as they are no longer part of Bazel core.

How to migrate to 0.8.4:

1. You will need to update references to the mayhem_run() rule so that they call bazel run instead of bazel build (note: bazel build will technically still work, but it doesn't do anything other than generate the run script).
2. If you are on Windows, you'll need to add common --enable_runfiles (or common:windows --enable_runfiles if you are using platform-specific configuration).
3. If you were referencing junit or sarif files from the bazel-rules_mayhem root directory, you will now want to grab these from the target runfiles directory.

Full Changelog: 0.8.3...0.8.4

0.8.3

What's Changed

• Windows path by @xansec in #14

Full Changelog: 0.8.2...0.8.3

0.8.2

What's Changed

• Fully implicit login by @xansec in #11

Full Changelog: 0.8.1...0.8.2

This release includes a few more bugfixes related to symlinks in Windows. It also removes mayhem_login entirely, and opts for a fully implicit login process. This should reduce build time and overhead for unnecessary login commands.

0.8.1

What's Changed

• Home login by @xansec in #10

Full Changelog: 0.8.0...0.8.1

This release reverts the changes made in 0.7.8 and 0.8.0, opting for alternative that does not rely on workspace level secret files. This implementation takes advantage of the fact that Mayhem normally stores login credentials in a default config directory, and respects XDG_CONFIG_HOME. By combining the two, we can give bazel information about where the credentials are without actually exposing them, and rely on the Mayhem CLI to use the credentials for running commands. I believe this solves the security issue.

Note that this is a breaking change. Instead of specifying --action_env=MAYHEM_TOKEN=$MAYHEM_TOKEN, users must now specify their config home with --action_env=XDG_CONFIG_HOME=$XDG_CONFIG_HOME. (Usually, this is ~/.config.)

0.8.0

Full Changelog: 0.7.7...0.8.0

This includes everything from 0.7.8, but bumping to subminor change since this is a breaking change for this rule.

This release includes a breaking change and security update. Previously, Mayhem tokens passed by --action_env could be read in the logs of the remote Bazel cache. Normally, this would only be an issue if an external party had access to the bazel cache. However, some customers share their cache across their organization, which would allow members of one team to view the logs in the cache from another team. Tokens are cheap and easy to regenerate, but Mayhem does not enforce an expiration for tokens, so these leaks can become a problem. The new solution uses a credential file in the user's Bazel workspace to provide credentials for login instead, keeping them out of the remote cache.