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
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions .changeset/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Changesets

Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
with multi-package repos, or single-package repos to help you version and publish your code. You can
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 🎉

18 changes: 18 additions & 0 deletions .changeset/config.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
{
"$schema": "https://unpkg.com/@changesets/config@2.2.0/schema.json",
"notes": {
"overall config docs": "https://github.com/changesets/changesets/blob/main/docs/config-file-options.md",
"changelog customization": "https://github.com/changesets/changesets/blob/main/docs/modifying-changelog-format.md"
},
"changelog": [
"@changesets/changelog-github",
{ "repo": "CrowdStrike/ember-headless-form" }
],
"commit": false,
"fixed": [],
"linked": [],
"access": "public",
"baseBranch": "main",
"updateInternalDependencies": "patch",
"ignore": ["test-app"]
}
9 changes: 9 additions & 0 deletions .changeset/pre.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
{
"mode": "pre",
"tag": "beta",
"initialVersions": {
"ember-headless-form": "0.0.0",
"test-app": "0.0.0"
},
"changesets": []
}
41 changes: 41 additions & 0 deletions .github/actions/assert-build/action.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
name: Build and Assert Assets Exists
description: Build the package and assert that file contents exist as we expect

# This task also uploads the built assets to a per-ci-run cache, so that
# we can be certain there is no flaky build behavior between the ci jobs
runs:
using: "composite"
steps:
- name: Build and Assert Output
shell: bash
# This isn't meant to assert all files exist,
# but is intended to make sure nothing catestrophic happens with the build
# or would negatively affect consumers once published.
# We require:
# - js maps
# - declaration files
# - declaration maps (these don't occur on all files)
run: |-
echo '
target: ${{ env.dist }}
setup:
run: pnpm build
cwd: ./ember-headless-form
expect: |
index.js
index.js.map
index.d.ts
template-registry.js
template-registry.js.map
template-registry.d.ts
components/-private/capture-events.d.ts
components/-private/capture-events.d.ts.map

' >> assert-contents.config.yml
npx assert-folder-contents

- name: Upload dist assets to cache
uses: actions/upload-artifact@v3
with:
name: dist
path: ${{ env.dist }}
24 changes: 24 additions & 0 deletions .github/actions/download-built-package/action.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
name: Download built package from cache
description: Download built package from cache
runs:
using: "composite"
steps:
- name: Download built package from cache
uses: actions/download-artifact@v3
with:
name: dist
path: ${{ env.dist }}
- name: 'Install dependencies'
shell: 'bash'
# Handle issue where pnpm does not re-sync dependencies
# when using dependenciesMeta.*.injected: true
#
# For more information see:
# - https://github.com/pnpm/pnpm/issues/4965
# - Possible solution: https://github.com/pnpm/pnpm/issues/4965#issuecomment-1405264290
# - Related issues:
# - https://github.com/pnpm/pnpm/issues/4625
# - https://github.com/pnpm/pnpm/issues/4988
# - https://github.com/pnpm/pnpm/issues/4625
# - https://github.com/pnpm/pnpm/issues/6002
run: pnpm install --force
14 changes: 14 additions & 0 deletions .github/actions/pnpm/action.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
name: Setup node and pnpm
description: Setup node and install dependencies using pnpm
runs:
using: "composite"
steps:
- uses: pnpm/action-setup@v2.2.4
with:
version: 7
- uses: actions/setup-node@v3
with:
cache: 'pnpm'
- name: 'Install dependencies'
shell: 'bash'
run: pnpm install
122 changes: 122 additions & 0 deletions .github/renovate.json5
Original file line number Diff line number Diff line change
@@ -0,0 +1,122 @@
// Docs:
// 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!

],
"automerge": true,
"masterIssue": true,
// bump for apps
// update-lockfile for addons/libraries
"rangeStrategy": "update-lockfile",
// From the docs:
// https://docs.renovatebot.com/configuration-options/#packagerules
// Important to know: Renovate will evaluate all packageRules and not stop once it gets a first match.
// Therefore, you should order your packageRules in order of importance so that later rules can override
// settings from earlier rules if necessary.
//
// (so if something is to be disabled, place that rule last)
"packageRules": [
////////////////////////////////////////
// Grouping namespaced packages together
//
// This reduces overall PR count
////////////////////////////////////////
{
"groupName": "Type Definitions",
"packagePatterns": ["^@types\/*"],
"schedule": ["after 9pm on sunday"]
},
{
"groupName": "Lint Dependencies",
"schedule": ["after 9pm on sunday"],
"packageNames": [
"eslint",
"babel-eslint",
"ember-template-lint",
"prettier"
],
"packagePatterns": [
"eslint-plugin-.*",
"eslint-config-.*",
".*typescript-eslint.*",
"^@commitlint\/*",
"^remark-*"
]
},
// 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.

"packageNames": [
"@ember/optional-features",
"@glimmer/component",
"@glimmer/tracking",
"ember-disable-prototype-extensions",
"ember-export-application-global",
"ember-load-initializers",
"ember-maybe-import-regenerator",
"ember-resolver",
"ember-source",
"ember-cli-page-title"
]
},
{
"groupName": "CLI Dependencies",
"packageNames": [
"broccoli-asset-rev",
"ember-cli",
"ember-auto-import",
"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

]
},
{
"groupName": "Testing Dependencies",
"schedule": ["after 9pm on sunday"],
"packageNames": [
"qunit-dom",
"ember-try",
"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

]
},
{
// We will handle this ourselves
"groupName": "Automated Release Dependencies",
"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

]
},
{
// Max Semver compatibility
"packagePatterns": [
"@ember/test-waiters"
],
"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!

"matchDepTypes": ["peerDependencies"],
"enabled": false
},
{
// ensure maximum compatibility, when possible
"matchPaths": ["ember-headless-form/package.json"],
"matchDepTypes": ["dependencies"],
"enabled": false
},
{
// changing engines forces other people to need to upgrade their minimum node
// therefor engine changes are breaking changes
"depTypeList": ["engines"],
"enabled": false
}
]
}
Loading