Clarify the createReadme flag options

[only1chunts]

User story

As a curator
I want to know what all the different flags mean on the createReadme script
So that I know which options to use and when

Acceptance criteria

Given there is a script called createReadme
When I come to use it
Then I can understand what the following flags mean for me:
--wasabi
--apply
--use-live-data
--doi (this one is already well documented, but adding it here for completeness)
--batch (I dont think curators really need to use it, but its useful to have documentation about it)

Additional Info

descriptions from Peter:

Dry-run mode will output the readme file onto your screen but it will not upload readme file into Wasabi. This is useful if you wanted to check the readme file to ensure the content is as it should be, e.g. list of authors is in correct order.

By default, the createReadme script is in run dry-mode, you need to include --apply flag to upload readme file into Wasabi.

There are 3 directories in the Wasabi bucket that contains GigaDB datasets: dev, staging and live which mirror the environments we have for GigaDB. By default, readme files are uploaded into staging directory for testing purposes. The —use-live-data flag is required for uploading the readme file into the live directory in Wasabi where all the production GigaDB dataset files are located.

But if the --apply and the --use-live-data flags make it send stuff to wasabi, I dont understand what the --wasabi flag does?
What is "dry-run mode"? why do we need it?

Product Backlog Item Ready Checklist

• Business value is clearly articulated
• Item is understood enough by the IT team so it can make an informed decision as to whether it can complete this item
• Dependencies are identified and no external dependencies would block this item from being completed
• At the time of the scheduled sprint, the IT team has the appropriate composition to complete this item
• This item is estimated and small enough to comfortably be completed in one sprint
• Acceptance criteria are clear and testable
• Performance criteria, if any, are defined and testable
• The Scrum team understands how to demonstrate this item at the sprint review

Product Backlog Item Done Checklist

• Item(s) in increment pass all Acceptance Criteria
• Code is refactored to best practices and coding standards
• Documentation is updated as needed
• Data security has not been compromised (with particular reference to the personal information we hold in GigaDB)
• No deviation from the team technology stack and software architecture has been introduced
• The product is in a releasable state (i.e. the increment has not broken anything)