Automatic scan

Automatic scan replaces the export by hand: a job you run reads your flows with your own Atlassian API token, replaces every text by a placeholder, and sends them, in chunks, to your TuneCraft app, which runs on Atlassian's cloud. Jira admins set it up on the Scan page, and Plugincraft never receives the flows.

Where to find it

Where the data goes

The job runs where you set it up: your own machine, scheduler or CI, or, for the ScriptRunner sender, a scheduled job inside an app from another publisher that your site has installed. It calls three places only: your own Jira site, Atlassian's API, and the receiver address of your TuneCraft app. The job only reads your flows and changes no flow or setting in Jira. Everything the app receives is processed on Atlassian's cloud.

• The job replaces every text by a placeholder before it sends anything, in the same way as the Scan page. The app checks every flow again and refuses the whole push if one still holds a text.
• Your API token never reaches the app or Plugincraft. The job uses it only to call Atlassian. With the ScriptRunner sender, the token is kept in that app's Script Variables.
• The key you make on the Scan page is a different thing: it lets the job push to your app. TuneCraft shows it once and keeps only a hash of it.
• The one thing the ScriptRunner job writes is a Jira user property, tunecraft-scan (counters and a cursor, no flow text), on the account that runs it, so that a large site can be sent over several runs. The job clears it when a push is complete.

Set up a sender

Step 1: Make a key

Open Scan, find Automatic scan and select Make a key. Copy the key now.

Important: The key is shown once. If you lose it, select Replace the key: the old key stops working at once, so update every job that uses it.

Step 2: Choose a sender

Under Set up a sender, choose one: Node.js, PowerShell, Python or ScriptRunner. The next section says what each sends. For ScriptRunner, follow the seven steps on its card, described below, instead of steps 3 to 7.

Step 3: Download the file

Download the file and put it where the job runs.

Step 4: Set the five settings

Set five settings in the environment: ATLASSIAN_SITE (your site's address, as in your Jira web address), ATLASSIAN_EMAIL, ATLASSIAN_API_TOKEN, TUNECRAFT_URL (the Receiver address) and TUNECRAFT_KEY (the key). Make the token on Atlassian's token page: nobody can make one for you.

Important: Keep the settings in your scheduler's secret store, never in a file under version control.

Step 5: Run a dry run

Run the sender as a dry run. It reads and redacts your flows, shows counts and sends nothing.

Step 6: Run it for real

Run it again without the dry run. The card shows the push when it arrives, under Last push.

Step 7: Schedule it

Run it every day. Any scheduler you already run can start the sender, and the card gives examples.

To stop the automatic scan at once, select Turn off. The key stops working and no push is accepted. The scans already saved stay.

The four senders and what each sends

Every sender reads each flow in full, replaces its texts where it runs (on your own machine, scheduler or CI, or, for ScriptRunner, inside that app from another publisher), and sends its steps with every text replaced, in chunks, with a summary of each flow. Three of them also send what the checks beyond the summaries need: what your flows name (by Jira's id or by a keyed code of the name, never the name), counts of credentials, addresses and web requests, and the account ids the steps name. Those texts are found on each flow's real text, where the sender runs. Each sender has a dry run that sends nothing.

The ScriptRunner sender

• The card has seven numbered steps, each with a box to tick, and a drawing of where to click where a step needs one. Keep the card open in one tab and use Jira in a second one.
• A dry run in that app takes about 2 minutes.
• The job stops after 240 seconds: the script stops reading at 180 seconds, sends what it has, and carries on at the next run, so a large site is sent over several runs.
• A job is kept only when you press Save in that app.
• The card shows no job to copy while no key is in the page, because a key is shown once. If your job already runs, you need nothing and should not replace the key.

What a summaries-only sender leaves out

With PowerShell, a scan keeps no flow steps, no counts and no record of what your flows name. So Check before you delete, Governance and Broken flows use the latest earlier scan that held them and say its date, until a newer scan with them arrives. A push that keeps no references never replaces those of an earlier scan. The card's What this scan holds says, for each part, Held or Not held. If a scan holds less than it could, the card says which senders send everything.

What no sender can do

• No sender sends your flows' real text, and none checks your JQL. Optimize, Fix it with me and the checks of JQL still need your export on the Scan page.
• The Map, Dependencies, loops and flows another flow cannot start are worked out from the steps with every text replaced, which every sender sends. They can differ from a scan of your export: a step that sets fields through advanced fields (JSON) counts as possibly changing any field, and a field name in another letter case does not match. A scan of your export gives the exact answer.
• A site takes up to 6 pushes a day (UTC), a fixed limit. Flows a sender cannot send are counted and left out. A push of many flows is saved in several passes, in the background.

Keep an eye on it

• Last push shows when it came, how many flows were saved and what was left out. A refused push says why and what to do: for example "Refused: a flow still held a text. Update the sender, and run it again."
• Expect a push at least every takes 1 day, 2 days or 7 days. When no push has been saved for longer than that plus 6 hours, the card says The automatic scan is late. If the "Automation usage" option is ticked on the Alerts page, TuneCraft also creates one Jira work item for each late stretch.
• The schedule is kept by your sender, not by TuneCraft. To push more or less often, change the schedule where the sender runs.

What it changes in Jira and how to undo it

The job changes no flow or setting in Jira. Two things write to Jira: the alert for a late push, which comes from TuneCraft and only if a Jira admin turned it on, and the one user property of the ScriptRunner job.

Related pages

• Automation: the Scan page, the findings and the savings.
• Privacy and data: what leaves your browser and what is kept.
• Background jobs: the pushes and the day's count.

Questions about the app? Write to info@plugincraft.ca.