-
Notifications
You must be signed in to change notification settings - Fork 152
Release automation. #917
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.
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
Release automation. #917
Changes from 41 commits
525db20
15412d8
6b53a7b
a726a97
a103178
03af6a8
052e2c4
9425693
6554fc1
1afbe08
0f7cfa5
34611bd
bca0e66
0a6181a
40c9e68
2f072a4
56d618f
9939064
751f970
33359ad
c5cb8b1
667bad4
7d81961
61c45a3
656824b
36a982f
2048223
2311ab7
2c2158a
f6dbe2b
5a7244c
1bcefe5
281a25a
d0827cd
5e121db
7e1c65e
83653cc
350ee2e
917852a
a1244d8
f196a2d
6c67d4c
bf5bbcc
d935eaf
b6108a8
c12ca9c
beb63c7
191d3fd
864411a
edffbb7
fe0afbf
74b83e6
dec4e00
bf5d6fd
c4bd84a
61d1252
957f7e3
ffa9f6a
0f189cf
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| # Copyright 2025 The Flutter Authors. | ||
| # Use of this source code is governed by a BSD-style license that can be | ||
| # found in the LICENSE file. | ||
|
|
||
| # A CI configuration for pub-publish to write comments on PRs. | ||
|
|
||
| name: Comment on the pull request | ||
|
|
||
| on: | ||
| workflow_run: | ||
| workflows: | ||
| - Publish | ||
| types: | ||
| - completed | ||
|
|
||
| jobs: | ||
| upload: | ||
| uses: dart-lang/ecosystem/.github/workflows/post_summaries.yaml@main | ||
| permissions: | ||
| pull-requests: write |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| # Copyright 2025 The Flutter Authors. | ||
| # Use of this source code is governed by a BSD-style license that can be | ||
| # found in the LICENSE file. | ||
|
|
||
| # A CI configuration to auto-publish pub packages. | ||
|
|
||
| name: Publish | ||
|
|
||
| on: | ||
| pull_request: | ||
| branches: [ main ] | ||
| types: [opened, synchronize, reopened, labeled, unlabeled] | ||
| push: | ||
| # Match <package-name>-v<version> publish tags | ||
| tags: [ '[A-z0-9]+-v[0-9]+.[0-9]+.[0-9]+' ] | ||
|
|
||
| jobs: | ||
| publish: | ||
| if: ${{ github.repository_owner == 'flutter' }} | ||
| uses: dart-lang/ecosystem/.github/workflows/publish.yaml@main | ||
| with: | ||
| # See https://github.com/dart-lang/ecosystem/tree/main/pkgs/firehose#options | ||
| sdk: beta # version of dart sdk to use for publishing | ||
| use-flutter: true | ||
| write-comments: false | ||
| checkout_submodules: false | ||
| permissions: | ||
| id-token: write | ||
| pull-requests: write |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,74 @@ | ||
|
|
||
| # Publishing | ||
|
|
||
| Publishing to [pub.dev](https://pub.dev) happens automatically via GitHub Actions, with the help of | ||
| [firehose rules](https://github.com/dart-lang/ecosystem/tree/main/pkgs/firehose). | ||
|
|
||
| There are two CI workflows that enable this automation: | ||
|
|
||
| 1. [post_summaries.yaml](../../.github/workflows/post_summaries.yaml) - job `publish / validate` runs on pre-submit. | ||
| 2. [publish.yaml](../../.github/workflows/publish.yaml) - job `publish / publish` runs on tagging. | ||
|
|
||
| ## Passing the publish / validate job | ||
|
|
||
| In general, the job [publish / validate](https://github.com/flutter/genui/actions/workflows/post_summaries.yaml) checks if all pub.dev packages are ready for publishing. | ||
|
|
||
| To make sure your PR passes this validation, follow [firehose rules](https://github.com/dart-lang/ecosystem/tree/main/pkgs/firehose). | ||
|
|
||
| ## Package categories | ||
|
|
||
| Packages in this repo fall into the following categories: | ||
|
|
||
| 1. **Not published**: `pubspec.yaml` contains `publish_to: none`. Workspace tools and example apps that are never pushed to pub.dev. | ||
| 2. **Not yet published**: the package's `version:` ends with a `-dev<N>` suffix (see "`-dev` vs non-`-dev`" below). Published to pub.dev only to reserve the name; not ready for general use yet. | ||
| 3. **Published**: any other package. Each has its own version cadence on pub.dev. | ||
|
|
||
| Note: `resolution: workspace` in a `pubspec.yaml` is a tooling concern — it tells Dart to share dependency resolution and a lockfile with the monorepo, and it does **not** by itself imply anything about release cadence. A package can opt out of the workspace (omit `resolution: workspace`) to avoid circular dependencies or unrelated update churn while still being a published package. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If a package opts out of the monorepo, however, it is then implicitly switching to using published packages only, and local changes won't be testable without manual editing of the pubspec files to use local paths, or publishing the dependent packages. How does using the monorepo increase circular dependency problems? It seems like it would make them better, not worse, since you're using the local versions of the code. But maybe I don't understand the use case you're describing. And what kind of "update churn"? Since it doesn't imply anything about release cadence, I wouldn't think that would increase the churn. Are you referring to churn in publishing other packages, or churn the package that is part of the monorepo?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you! Yes this documentation was confusing and some sentences are wrong. Updated. We still use advantages of monorepo. Added section to explain how. |
||
|
|
||
| ## `-dev` vs non-`-dev` (production ready) versions | ||
|
polina-c marked this conversation as resolved.
|
||
|
|
||
| The packages code should be always release ready. That means: | ||
|
polina-c marked this conversation as resolved.
|
||
|
|
||
| 1. Use `-dev` version if **at least one** of the following statements is true: | ||
|
|
||
| 1.1. The package is planned to be released in the future. In this case it is published with `-dev` suffix in order to reserve the package name. | ||
|
|
||
| 1.2. The package's changes touch only non-publishable code or docs (like tests, tools, or not-publishable docs). | ||
|
|
||
| You can publish `-dev<number>` versions, if you need it for development. | ||
|
polina-c marked this conversation as resolved.
Outdated
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What is the format of e.g. which of these is it?:
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you. Updated doc.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see a description of the format of
polina-c marked this conversation as resolved.
Outdated
|
||
|
|
||
| 2. If your feature is partially implemented, hide the feature's code behind a false-by-default flag, and use **release-ready** version. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where are the flags specified? Are they
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We do not have it organized yet. Documented that it is not defined yet. |
||
|
|
||
| ## Versioning | ||
|
|
||
| We use [Semver] for package versioning, although before 1.0.0, we will be | ||
| incrementing only the minor number for breaking changes and the patch number for | ||
| non-breaking changes. After 1.0.0, we will be using standard Semver, bumping the | ||
| major number for breaking changes. | ||
|
|
||
| <!-- references --> | ||
|
|
||
| [Semver]: https://semver.org/ | ||
|
|
||
| ## How publishing happens? | ||
|
|
||
| TODO(polina-c): add information, https://github.com/google/A2UI/issues/1383 | ||
|
|
||
| ## How upgrade of dependencies (for both siblings and third party) happens? | ||
|
|
||
| ### For local development runs | ||
|
|
||
| For packages with `resolution: workspace` in their pubspec.yaml, pub resolves every sibling from its local source directory — not from pub.dev, as long as its `version:` satisfies the consumer's constraint. | ||
|
|
||
| If a local bump escapes that constraint (e.g. `^0.9.0` → `0.10.0`), update the consumer's `pubspec.yaml` in the same PR. Otherwise pub silently falls back to the published version on pub.dev. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we have a check for this?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good idea! added |
||
|
|
||
| ### For runs by external packages | ||
|
|
||
| After a new version of a dependency (including sibling package in this repo) is published, this is how upgrade will happen: | ||
|
|
||
| 1. [Dependabot] detects the new version on pub.dev and opens a PR per dependency, bumping the constraint in each consuming `pubspec.yaml`. See [About Dependabot version updates] for details. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there any way to add a new section to each
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not natively — Dependabot only edits the manifest. I filed a feature request upstream: dependabot/dependabot-core#15057. For now the doc calls out that the
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Filed an issue and added comment: dependabot/dependabot-core#15057 |
||
| 2. The PR runs `publish / validate` and the rest of CI. | ||
| 3. A maintainer reviews and merges the PR. | ||
|
|
||
| [Dependabot]: ../../.github/dependabot.yaml | ||
| [About Dependabot version updates]: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Authoring pull requests | ||
|
|
||
| ## Make your PR easy to review | ||
|
|
||
| 1. Make sure your PR has meaningful title and description. | ||
| 2. Make sure your PR is not too large. Smaller PRs are easier to review. | ||
| 3. Separate code reorgs from feature changes. | ||
|
|
||
| ## CI presubmit errors | ||
|
|
||
| You may get CI presubmit errors on pull requests for several reasons. This section explains how to fix some of the less obvious ones. | ||
|
|
||
| ### From `publish / validate` job | ||
|
|
||
| In general, the job checks if all [pub.dev](https://pub.dev) packages are release ready. | ||
|
|
||
| See [publishing.md](publishing.md) for more details. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,5 @@ | ||
| # `a2ui_core` Changelog | ||
|
|
||
| ## 0.0.1 (in progress) | ||
| ## 0.0.1-dev002 | ||
|
|
||
| - Initial version. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,5 @@ | ||
| # `genai_primitives` Changelog | ||
|
|
||
| ## 0.2.4 (in progress) | ||
|
|
||
| - **Refactor**: Update core framework to v0.9 (#546dab9be). | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment is now lost. When will it be added back in? Shouldn't there be a section for in progress (-dev) changes?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But what about in-progress changes: Say I've committed something that isn't meant to be published yet, but I want to accumulate CHANGELOG entries for it when it is published. How am I supposed to do that? I would think there would be a
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, you are right. And this change is samll enough to hold for next release. Changed. |
||
|
|
||
| ## 0.2.3 | ||
|
|
||
| - **Feature**: Add methods `copyWith` and `concatenate` to `ChatMessage` (#760). | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| # `genui` Changelog | ||
|
|
||
| ## (WIP) | ||
| ## 0.9.1 | ||
|
|
||
| - **Feature**: Updated example/README.md. | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also add instructions for where to run the script from on the command line: not everyone uses VSCode, and that key binding is Mac-only, so you might include the default Linux keybinding too (which is likely to be the same as Windows). They also might have changed the keybinding...