Clarify process for deploying a pre-release #1100
Conversation
| There should now be a branch `pre-release-[your-branch-name-here]` pushed to remote, which you can install with: | ||
| There should now be a branch `pre-release-[your-branch-name-here]` pushed to remote. | ||
|
|
||
| 5. In GOVUK Design System: |
There was a problem hiding this comment.
I think this is useful, but I think there are use cases for pre-releases that do not involve a change to the Design System, and this change will be confusing for those users.
For example, if a team wanted us to make a change to an existing component and we wanted to be able to share a pre-release with them so they could test it, they would install the pre-release branch in their own application, not the Design System.
I suggest making it clear that this step is optional, splitting it out entirely or keeping it generic.
(Minor: GOV.UK, not GOVUK)
| ``` | ||
|
|
||
| 6. Test the changes updates using `npm test` |
There was a problem hiding this comment.
I'm not sure it's clear that this is in the Design System rather than back in Frontend – I certainly interpreted as running these in the Frontend repo initially.
NickColley
force-pushed
the
update-pre-release-docs
branch
from
ed97fd8 to
e380587
Compare
Changes are needed in two different repos and the existing README does not explain this well.
NickColley
force-pushed
the
update-pre-release-docs
branch
from
e380587 to
5f99ae7
Compare
|
With Alistair's permission I've updated this based on @36degrees 's feedback. It's simpler but I think takes time to make clear to run this command in another project, which I think could be the main cause for confusion. Let me know if this is good to go @aliuk2012 @36degrees |
Something I picked up while pairing with Nick to update the Accordion's preview link.
Changes are needed in two different repos and the existing README does
not explain this well.