Skip to content

Commit

Permalink
Document input constraints and extend descriptions, announce bh dispa…
Browse files Browse the repository at this point in the history
…tch and new UI (#4)

* Document input constraints and extend descriptions

* Announce new personal access token and bh 0.2.0 release
  • Loading branch information
nikola-jokic authored Feb 17, 2025
1 parent 000208d commit 6283fa2
Show file tree
Hide file tree
Showing 3 changed files with 2,631 additions and 1,439 deletions.
10 changes: 8 additions & 2 deletions content/1.workflows/1.syntax.md
Original file line number Diff line number Diff line change
Expand Up @@ -274,15 +274,19 @@ act differently depending on the input provided. For the ones who are also softw
There are two primary reasons to use dispatch:

1. From time to time, you want to run scan on a specific program by triggering it manually. Inputs are completely defined by the program
(for example, program domain(s), ips, etc.)
2. You want to dispatch something from your scan. Let's say you uncovered a new domain. You want to spawn a new pipeline to check stuff
(for example, program domain(s), IPS, etc.)
2. You want to dispatch something from your scan. Let's say you uncovered a new domain. You want to spawn a new pipeline to check stuff
*only* on that particular domain.

### `scans.[ID].on.dispatch.inputs.[KEY]`

Key is a unique identifier for an input. It conforms to constraints related to project variables, but can be accessed from workflow expression
like `${{ inputs.[KEY] }}`.

There are few constraints you should be aware of:
- Maximum number of inputs is 20.
- Maximum size of dispatch values is 65535 characters. If you need larger input size, consider uploading assets and passing down the reference to it.

### `scans.[ID].on.dispatch.inputs.[KEY].type`

Type of this YAML key is `string`. The value is either `string` or `bool`. By default, it is of type `string`.
Expand All @@ -292,6 +296,8 @@ Type of this YAML key is `string`. The value is either `string` or `bool`. By de
Type of this YAML key is `boolean`. By default, it is `false`. If you specify `required: true`, it would mean that you **MUST** provide the value
when spawning the job.

As a side-note, all values are provided by default from UI. Empty value is still a provided value. This limitation is mostly important for API calls (e.g. `bh scan dispatch ...`)

### `scans.[ID].on.dispatch.inputs.[KEY].default`

Type of this YAML key is `string`. However, if you specify `type` to be `bool`, valid values are `"true"` or `"false"`. Otherwise, since the only supported
Expand Down
37 changes: 37 additions & 0 deletions content/999.announcements/1.all.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,43 @@ title: "Announcements"

# Announcements

## Announcing new Personal Access Token UI along with `bh` 0.2.0 release

New addition of dispatch inputs to the workflow must go hand in hand with the ability to dispatch
inputs using the `bh` CLI. However, implementing this feature I noticed that handling personal access
tokens is suboptimal, and the interface was quite bad. So I decided to rework the current PAT token implementation,
along with the newest addition to this release.

New PAT is in the same format, it is completely backwards compatible, and you shouldn't see any disruptions
with your old PAT. But the UI is much simpler, and allows now re-generation of the same token, along with
token expiry dates.

New scopes are added, but are not yet part of the `bh` tool since I'm not yet sure how to properly output it.

If you have any ideas, please submit a [feature request](https://github.com/bountyhub-org/bh/issues/new),
submit [feedback](https://forms.gle/2xtWVJENLAf3XJjA9), or let me know via an e-mail.

It never hurts to mention that [support page](https://bountyhub.org/support) is built, so you can easily
find links that you need.

Important thing to mention is that new `bh` release comes with the `env` fallback. All `env`s are prefixed
with `BOUNTYHUB_` which serves as a namespace, so they don't override your common environment variables.

Having said that, new runner will be released soon, and will expose these environment variables for each step.
This would massively simplify download steps where mostly, you would just have to specify the `-j` flag and the
`-o` flag.

Preview:

```bash
# Old usage
bh job download -p ${{ project.id }} -w ${{ workflow.id }} -r ${{ revision.id }} -j ${{ scans.subfinder[0].id }} -o output.zip
# New and shiny use
bh job download -j ${{ scans.subfinder[0].id }} -o output.zip
```

As always, happy hunting!

## Runner version 0.3.0 is released

Along with the [Major back-end release](#major-back-end-release), new runner release is created.
Expand Down
Loading

0 comments on commit 6283fa2

Please sign in to comment.