Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

automated publishing #863

Closed
cyberhck opened this issue May 16, 2019 · 2 comments
Closed

automated publishing #863

cyberhck opened this issue May 16, 2019 · 2 comments
Labels
Domain: Releases Scheduling and infrastructure around package releases. Domain: Tooling Repository tasks around improving source tooling. Status: In Discussion Please continue discussing the proposed change before sending a pull request.

Comments

@cyberhck
Copy link
Contributor

following discussion from #852 (comment) I was thinking adding some automation will do some good.

I can think of 3 ways,

First, we'd do semantic-release, it'll do everything, commenting on PR after it's released, adding tags, creating a github release, adding change logs, etc. We'd need to commit in a certain format for this to work, we can easily verify that using git hooks and a commit message linting on CI as well.

Second, we release once the tag is pushed, but use release-notes-generator to get the change log and make a proper github release, can be a tiny bit more work, but can work, but we'd still have to commit in a particular format, but if we're doing this anyway, why not just do the first one, and by default merge PRs to release branch, then periodically merge release branch to master, and master can release whatever was in release branch (and release branch can be set in a way that we release beta versions there)

third, release with the tags, without proper commit messages, but there won't be a nice change log generator, this means one would have to manually go and create change logs.

If you want to go for first option, I can setup a PR and see if everything works :)

@IllusionMH IllusionMH added Domain: Tooling Repository tasks around improving source tooling. Status: In Discussion Please continue discussing the proposed change before sending a pull request. labels May 16, 2019
@IllusionMH
Copy link
Contributor

Thank you for the issue, details for three options to consider, and PR proposal!
My message in linked PR wasn't clear enough so will add more details here.

I saw this proposal and I'm leaning towards first approach but with local releases using --no-ci flag (at least initially)
However before adding and configuring semantic-release there are few steps that should be taken:

  1. Releases should be done from master branch instead of separate releases branch (something like Use in-place compilation instead of directory swapping #825 or other process)
  2. How PRs are merged into master to support correct message format
  3. Revisit approach for beta versions to just rely on npm dist-tags (because AFAIK semantic-release doesn't support x.y.z-beta)
    May be something more.

At this point I'm working on proposals for points above and they will be ready next week.

@cyberhck
Copy link
Contributor Author

Not sure about -beta, but there's a pre release feature, a while ago I was curious about this

yes, we can go for --no-ci flag as well, true, the details can be figured out slowly and by considering what everyone thinks, obviously I don't know the whole thing about it, just wanted to push the idea forward :)

@IllusionMH IllusionMH added the Domain: Releases Scheduling and infrastructure around package releases. label May 26, 2019
@cyberhck cyberhck closed this as completed Oct 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Domain: Releases Scheduling and infrastructure around package releases. Domain: Tooling Repository tasks around improving source tooling. Status: In Discussion Please continue discussing the proposed change before sending a pull request.
Projects
None yet
Development

No branches or pull requests

2 participants