Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Automated versioning and releases #11

Open
slifty opened this issue May 12, 2020 · 2 comments
Open

Automated versioning and releases #11

slifty opened this issue May 12, 2020 · 2 comments
Labels
devops help us make is possible to make things discussion The conversation is the point
Projects
Engineering Team

Comments

@slifty
Copy link
Member

slifty commented May 12, 2020 •
edited
Loading

Discussion

What do you want to talk about?

After we set up #9 we're going to be releasing packages from this repository, which means we should figure out how we want to handle versioning.

Ideally we would automate as much about the release process as possible (without going completely nuts). This will also be useful for other projects (both in TVK and in life), so I'm OK spending a little bit of time on doing it Right.

Relevant Resources / Research
@slifty slifty added the discussion The conversation is the point label May 12, 2020
@slifty slifty mentioned this issue May 16, 2020
Closed
@slifty slifty added the devops help us make is possible to make things label May 21, 2020
@slifty slifty added this to Ice Box in Engineering Team via automation May 21, 2020
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Separate package lifecycle scripts a little better
f082355 
There are lots of yak-shaving pot-holes here, but I think this makes
sense according to the npm documentation:
https://docs.npmjs.com/misc/scripts

- Add a `pretest` script that builds the app; this is important so
  local sibling dependencies are testing the newly-built code.
- Move `yarn build` from `prepublishOnly` to `prepare`. According to the
  npm scripts docs, `prepare` is slightly more appropriate for build
  steps, while `prepublishOnly` is appropriate for publish-blocking test
  suites. (There’s a redundancy here, in that `yarn test` also builds
  thanks to the newly-added pretest above, but I think we’ll have to
  swallow that.)

Affects #11

Signed-off-by: Justin Reese <justin@justinreese.com>
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Revert versions to 0.0.0 before first publish
d6f2b6b 
According to the docs in a [well-linked Lerna guide][lerna], we should
start our brand new packages at 0.0.0 and let Lerna increment them
during publishing.

Affects #11

[lerna]: https://medium.com/@jsilvax/a-workflow-guide-for-lerna-with-yarn-workspaces-60f97481149d#a4cf

Signed-off-by: Justin Reese <justin@justinreese.com>
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Correct the files included when publishing to npm
3e17bc9 
This commit contains two changes to the `files` configuration for
publishing to npm:

- Corrects `dist/` to `lib/` to reflect our current build destination
  (see the `build` script command)
- Adds `src/` so original ES6 source is available for those users who
  want it

Affects #11

Signed-off-by: Justin Reese <justin@justinreese.com>
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Add repository information to package info
03626a6 
This decorates each package’s `package.json` file with their repository
info, following the guidance of other monorepos.

Affects #11

Signed-off-by: Justin Reese <justin@justinreese.com>
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Add license to package info
710adb4 
This risks being redundant but it seems to match other monorepos like
Babel.

(Babel is inconsistent about including a license _file_ in every child
repo, so for now I’ll err on the side of simplicity.)

Affects #11

Signed-off-by: Justin Reese <justin@justinreese.com>
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Add READMEs for each package
8f4688c 
Following the monorepo design guidance of Babel, this provides minimal
per-package description and (eventually) installation guidance, while
giving npm some information to render about the package.

Affects #11

Signed-off-by: Justin Reese <justin@justinreese.com>
@reefdog reefdog mentioned this issue May 26, 2020
Closed
4 tasks
reefdog added a commit that referenced this issue May 26, 2020
@reefdog
Add READMEs for each package
dc430e7 
Following the monorepo design guidance of Babel, this provides minimal
per-package description and installation guidance, while giving npm some
information to render about the package.

Affects #11

Signed-off-by: Justin Reese <justin@justinreese.com>
@reefdog reefdog mentioned this issue May 26, 2020
Merged
4 tasks
@slifty
Copy link
Member Author

slifty commented Jun 5, 2020

As an interim step, should we build a habit of indicating major / minor / patch as part of a given changelog line?

@slifty
Copy link
Member Author

slifty commented Jul 11, 2020 •
edited
Loading

We've done a few releases now; not automated, but enough to document the process.

So far, we have been releasing packages one at a time (e.g. if 2 packages need to be published, they are done as two separate commits / steps)

  1. Build and test the package (yarn build and yarn test from the root directory)

  2. Update package.json

  • Increment the version according to SEMVER
  1. Update the CHANGELOG:
  • Create a new section for the new version number
  • Move Unreleased change log notes to the new section, minimizing edits but editing as appropriate.
  • Add a new diff link.

  1. Add a commit (git commit -m "Publish @tvkitchen/package-name@x.y.z")

  2. Tag the commit (git tag @tvkitchen/package-name@x.y.z)

  3. Push the commit and tag (git push --tags)

  4. Sanity check everything on GitHub

  5. Publish to npm from the package directory (npm publish)

There is lots of room for error. Also, ideally we would have some kind of beta / pre-release flow as well.

slifty added a commit that referenced this issue Jul 11, 2020
@slifty
Remove lerna
cbaab43 
For now we are not using lerna for anything, so lets remove it. We can
add it later if we want to use it for publishing (very likely)

Issue #39
Issue #11
This was referenced Jul 11, 2020
Merged
Open
slifty added a commit that referenced this issue Aug 1, 2020
@slifty
Remove lerna
1989b5c 
For now we are not using lerna for anything, so lets remove it. We can
add it later if we want to use it for publishing (very likely)

Issue #39
Issue #11
slifty added a commit that referenced this issue Aug 1, 2020
@slifty
Remove lerna
e43a9ec 
For now we are not using lerna for anything, so lets remove it. We can
add it later if we want to use it for publishing (very likely)

Issue #39
Issue #11
slifty added a commit that referenced this issue Aug 1, 2020
@slifty
Remove lerna
399dc30 
For now we are not using lerna for anything, so lets remove it. We can
add it later if we want to use it for publishing (very likely)

Issue #39
Issue #11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
devops help us make is possible to make things discussion The conversation is the point
Projects
Engineering Team
  
Ice Box
Milestone
No milestone
Development

No branches or pull requests
1 participant
@slifty