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.

0.7.8

What's Changed

• Login update by @xansec in #8
• Update readme by @xansec in #9

Full Changelog: 0.7.7...0.7.8

0.7.7

This release adds support for the following options with mayhem_run():

 --warning-as-error    Have the warnings be treated as errors.
 --ci-url CI_URL       Specify a URL to the Continuous Integration build you wish to associate with this run.
 --merge-base-branch-name MERGE_BASE_BRANCH_NAME, --scm-merge-base-branch MERGE_BASE_BRANCH_NAME
                        The destination branch of a changeset. For example, the destination branch in a GitHub Pull Request or GitLab Merge Request.
 --branch-name BRANCH_NAME, --scm-branch BRANCH_NAME
                        The source control branch for the code under test.
 --revision REVISION, --scm-sha REVISION
                        The source control commit hash for the current code under test.
 --parent-revision PARENT_REVISION, --scm-parent-revision PARENT_REVISION
                        The source control parent commit hash control parent commit sha on the current branch. This can also refer to revision on a different branch if the current branch does not havea
                        history of runs yet.
 --scm-remote SCM_REMOTE

To add, simply modify your mayhem_run():

mayhem_run(
   [opts]
   ci_url = "my-ci.url.com",
   [etc...]
)

0.7.6

New features:

• support junit and sarif output
• support CLI output
• updated documentation

Full Changelog: 0.7.5...0.7.6

0.7.5

• Added output_dir behavior for mayhem_download()
• Added login behavior
• Couple of bugfixes

Full Changelog: 0.7.4...0.7.5

Release 0.7.4

• Support custom URL for CLI download
• Support new rule mayhem_download for downloading coverage
• Update README

What's Changed

• update cli support by @xansec in #7

Full Changelog: 0.7.3...0.7.4

0.7.3

What's Changed

• Minor path separator bugfix for Windows

Full Changelog: 0.7.2...0.7.3