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.

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

Get ready for automated beta release, enable all C.I. checks #30

Merged
merged 6 commits into from
Feb 7, 2023

Conversation

NullVoxPopuli
Copy link
Contributor

@NullVoxPopuli NullVoxPopuli commented Feb 6, 2023

Same as: CrowdStrike/ember-toucan-core#14

To exit pre-release mode:

pnpm changeset pre exit

Docs: https://github.com/changesets/changesets/blob/main/docs/prereleases.md

Note that not every PR needs a changeset entry, and this is intentional -- especially as we work towards the baseline set of features.

But we do need at least one changeset to have our first beta release.
I've added the Changeset bot which provides instructions on how to make a changeset.

We do not expect external contributors to provide changesets.
The best workflow I've seen is for the PR reviewer (if contribution is external) to add the changeset to the PR before merge.

As a fallback, I've made another tool, demonstrated over here: embroider-build/embroider#1345
which allows you to double check contributions before release.


What's included in this repo's C.I.?

  • assert that source maps and type-maps are generated
  • support multiple versions of typescript, per https://www.semver-ts.org/
  • support multiple versions of ember-source, to ensure a smooth upgrade path for downstream consumers
  • support embroider so that downstream consumers can be assured that their dependencies are "embroider strict mode safe"
  • test with no lockfile to try to catch unintended ecosystem deviations / breaking changes (such as what may happen with babel / rollup / etc)

(all of the above is standard in ember OSS projects 🎉 )

extra stuff for this repo:

  • publish the docs site and post the preview URLs to PRs
  • configure the auto-release system to do a series of beta versions until we're ready for 1.0.0

What is supported?

  • minimum ember-source 4.8 -- we can start pretty new, but this also allows us to use the nicest features. Additionally, since we are beta, we can move the minimum ember-source to whichever ember-source ships the built-in-types (as non-preview), without a breaking change
  • TS 4.8 and 4.9 -- we cannot support earlier than TS 4.8, because Glint does not support prior to TS 4.8
  • embroider-strict and classic builds

(some of this was already happening -- but this is copy-pasta from toucan-core)

@changeset-bot
Copy link

changeset-bot bot commented Feb 6, 2023

⚠️ No Changeset found

Latest commit: 4f1de10

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@@ -21,6 +21,9 @@
"lint:hbs:fix": "ember-template-lint . --fix --no-error-on-unmatched-pattern",
"lint:js:fix": "eslint . --fix",
"lint:types": "glint",
"lint:prettier": "prettier -c .",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as an aside, I really like the workflow of having so much namespaced under lint. makes the number of commands to remember a lot less, and the pnpm --filter '*' at the top makes seeing the output wonderful

@@ -1,9 +1,6 @@
{
"extends": "@tsconfig/ember/tsconfig.json",
"include": [
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prettier 🤷

@@ -28,7 +28,7 @@
"devDependencies": {
"@ember/optional-features": "^2.0.0",
"@ember/test-helpers": "^2.8.1",
"@embroider/test-setup": "^1.7.1",
"@embroider/test-setup": "^2.1.1",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this upgrade fixes the issue that embroiderOptimized/safe was handling before: https://github.com/embroider-build/embroider/blob/main/CHANGELOG.md#embroidertest-setup-202---210

- uses: ./.github/actions/download-built-package
- run: pnpm --filter test-app test:ember

floating_tests:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

floating tests moved to here

@@ -67,22 +111,114 @@ jobs:
- ember-release
- ember-beta
- ember-canary
- embroider-safe
- embroider-optimized
- "'ember-lts-4.8 + embroider-safe'"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

embroider scenarios now say which ember-source they are using


floating:
name: 'Floating Dependencies'
typecheck:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new to CI: typescript matrix support

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

- uses: ./.github/actions/pnpm
# To be able to run glint, we need the dist directory
- uses: ./.github/actions/download-built-package
- name: Lint + Format + Glint
run: pnpm lint
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not all of our repos are doing an all-in-one lint command, but it's quite nice -- would be good to propagate this to everywhere

find the full documentation for it [in our repository](https://github.com/changesets/changesets)

We have a quick list of common questions to get you started engaging with this project in
[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have a section here for beta releases?

## Beta releases


npx changeset-recover@beta


edit the generated files to tidy up the generate Changelog entry:
   - select whether the change is a bugfix (patch), minor change, or major / breaking change
   - edit the changelog entry, which defaults to a combination of both the PR title and PR description - and if an associated PR can't be found, the commit message will be used (useful for direct commits to main)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changeset-recover is a fallback tool, for when the users of changeset don't want to use the changeset-recommended workflow. idk that it needs to be mentioned here.

All will be clear when we prepare for a release, I promise 🎉

Copy link
Contributor

@nicolechung nicolechung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

Copy link
Contributor

@simonihmig simonihmig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, thanks for tackling this!

I just left a few nit-picking questions, as they came up within this context, but nothing that should block us from merging this!

// These are dependencies that come default when
// generating a new ember addon
{
"groupName": "Framework Dependencies",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from @glimmer/*, these dependencies don't get released in-sync. So is there any benefit in grouping them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just less PRs if they do happened to get released close to each other, or if we're falling behind on updates. They tend to not cause problems for one another as far as I've been able to tell.

"ember-cli-dependency-checker",
"ember-cli-inject-live-reload",
"ember-cli-sri",
"ember-cli-terser"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

"ember-source-channel-url",
"ember-qunit",
"qunit",
"npm-run-all"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same

"enabled": false,
"packagePatterns": [
"@semantic-release*",
"semantic-release*"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we using those?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope! this is copy-pasta

"rangeStrategy": "widen"
},
{
// changing peerDependencies *at all* is a breaking change
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we never do breaking changes via Renovate, only manually? Not opposed to this, but seems easy to then forget to do this at all maybe?

Again in my previous company, we auto-merged all dev-stuff (linting/test/types deps) and minor/patch updates, but let a major bump raise a PR (see https://github.com/kaliber5/renovate-config/blob/main/default.json)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

auto-merging dev stuff is fine, but auto-merging peers affects consumers.

By default, renovate updates everything, with no respect to semver.

major bump raise a PR

this is a very nice layout to the renovate config.
I'd be open to creating a similar shared set of configs for our ember stuff, if you wanted to set that up?
And automerge: false is totally something we can do on certain things!

// https://docs.renovatebot.com/configuration-options/
{
"extends": [
"config:base"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't looked at other CS renovate configs, but are we always adding the whole config for each repo?

You can also share a centrally hosted config (here Github): https://docs.renovatebot.com/config-presets/#github-hosted-presets, in my previous company we have been doing this here...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but are we always adding the whole config for each repo?

yeah, we don't have a hosted config yet. sounds like a great idea!


floating:
name: 'Floating Dependencies'
typecheck:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

version: 7
- name: Install Node
uses: actions/setup-node@v3
persist-credentials: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You consider this best-practice, or any specific reason for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not persisting-credentials sounds nice. This is copy-paste from the Changesets/action README.md.
I don't have any reasons other than trust

@simonihmig simonihmig merged commit 3e5cdbb into main Feb 7, 2023
@simonihmig simonihmig deleted the get-ready branch February 7, 2023 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants