intuit / auto Goto Github PK

Is your feature request related to a problem? Please describe.

A few of us at Artsy are working on migrating a lot of repos over to use auto-release. In a batch session, I somehow managed to mess up the config and used noReleaseLabels instead of skipReleaseLabels on several of the projects. This caused some unnecessary releases.

Describe the solution you'd like

I think the config should be strictly validated. If there are values present that aren't a part of the config (i.e. noReleaseLabels), the release process should fail. Invalid configuration likely means someone is in for a bad time. Similarly if a config object doesn't match an expected type, etc. It seems like there's a start to a json schema that could be used for this purpose (auto-rc.json).

Describe alternatives you've considered

If you want to take a lighter approach I'd recommend at the very least having a validate command that checks the validity of the configuration.

Is your feature request related to a problem? Please describe.

use the platform!

Describe the bug

When running auto shipit v2 is failing unless you explicitly set the git user and password.

Here's a passing build with v1:
https://circleci.com/gh/artsy/renovate-config/727?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

and a failing build with v2 right after updating:
https://circleci.com/gh/artsy/renovate-config/737?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

To Reproduce

Updating to v2, ???

Expected behavior

Successful deploy without config change

Additional context

Having worked with process spawning, I suspect this is likely due to the git process not retaining its envs and context. I'm pretty sure this line is the culprit. PR inbound.

Is your feature request related to a problem? Please describe.

right now you can only configure a few changelog title even though the API supports as many as you want.

Add more prompts to init to get n labels from a user

Is your feature request related to a problem? Please describe.

right a bunch of logic lives in the CLI bin/auto.ts this should be moved to a main function. the CLI should only be a CLI

Is your feature request related to a problem? Please describe.

Slack URL should be configurable from CLI

Is your feature request related to a problem? Please describe.

Switch to @autorelease org.

Probably means renaming the repo too. I can help with this if you decide to do it @adierkens

• @autorelease/cli
• @autorelease/core

Describe the bug

I keep stealing all the commits

To Reproduce

run changelog, release, or shitpit locally. I become the author

Expected behavior

Shouldn't do that

use this https://www.npmjs.com/package/env-ci

Is your feature request related to a problem? Please describe.

Right now labels-init only creates the release labels. It should also create the changelog labels

Add some docs/examples around the .autorc file. It's referenced in the docs, but not really an example anywhere

Is your feature request related to a problem? Please describe.

I want to be able to publish a prerelease without using patch, minor or major. this should also publish under the alpha preid

Describe the solution you'd like

When there is just the prerelease label have auto version return prerleease

Is your feature request related to a problem? Please describe.

There are a few pitfalls that need documentation.

• no tag
• no release

Use the platform!

Is your feature request related to a problem? Please describe.

Currently changedPackages only considers packages in the /packages/ directory. This is the behavior of lerna-changelog the last time I looked.

Describe the solution you'd like

Support packages in any directory

Is your feature request related to a problem? Please describe.

If i don't have the neccasary environment variables auto should throw early and provide nice error messages with links to places to get tokens if possible.

Describe the bug

When printing out configuration via verbose mode it prints out the github token. If you're attempting to debug an issue on public CI this'll expose credentials to the public.

To Reproduce

Run auto shipit --very-verbose

Expected behavior

The github token should be sanitized or removed.

Screenshots

(this token was invalidated)

Is your feature request related to a problem? Please describe.

how do you use auto-release without the CLI

sounds better

Is your feature request related to a problem? Please describe.

We've had a few issues where a deployment fails because a particular version is already deployed. This isn't normal process that auto-release should come across... but it does happen. We had a bug last night and someone decided to manually deploy to npm without bumping the package.json version. That caused everything to get into a bad state that wasn't resolved until we manually bumped the version.

Describe the solution you'd like

Continue to update the version field in the package.json, but use npm's version as the source of truth. Give a warning if there's a missmatch, but update the version based off of the one on npm, not the one in the package.json.

Is your feature request related to a problem? Please describe.

auto should be bundled as a binary so that it can be distributed and consumed by other package ecosystems. (brew, apt-get, bower, whatever java uses)

possible bundlers:

• ncc
• parcel - in node mode
• https://github.com/zeit/pkg#readme maybe this is actually what i was thinking of

need to figure out interop with plugins

Is your feature request related to a problem? Please describe.

right now the init takes you through a bunch of options. a --labels flag to skip most setup and just setup the labels would be nice

standard-version

semantic-release

Is it a repetitive wheel?

Describe the bug

When an author name for an committer email cannot be found, auto currently displays undefined

To Reproduce

Expected behavior

Display just the email in this case.

Screenshots

Is your feature request related to a problem? Please describe.

once #31 is done. create meta CLI that does the publishing for you. This will be used in github actions

Is your feature request related to a problem? Please describe.

To facilitate other languages and more cool features we should make auto tappable.

Some hooks that might be useful:

• construct - tap into constructor creation, throw errors if secrets aren't present
• getUser - get git user
• getPreviousVersion - access package.json/pom.xml for previous version
• getRepository - get owner/repo
• publish - publish the package

Describe the bug

If you run yarn auto xxx - then your local git config is manipulated. It should probably only happen in yarn auto shipit and its substeps when deploying

To Reproduce

See the commits in #123, omakase-js/omakase@ccddab8 and artsy/reaction#1779

Expected behavior

Not editing local setup

Is your feature request related to a problem? Please describe.

Right now if you add a prerelease label it will make a prerelease version but it will publsih the prerelease to latest.

Describe the solution you'd like

publish under --preid=alpha

Is your feature request related to a problem? Please describe.

there are a bunch more version labels that can't be configure via CLI so it's better to remove this for V1

look at 0.36.3

look at the changelog

Is your feature request related to a problem? Please describe.

this script can remove the manual steps needed to migrate a repo that doesn't have it's latest release setup properly

Describe the bug

There are still many instances where commands fail but CI doesn't exit.

auto pr-check when some github response gives an error

https://circleci.com/gh/artsy/renovate-config/830?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

auto shipit when an npm package fails to be published

https://circleci.com/gh/artsy/reaction/22172?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

Expected behavior

CI Task fails appropriately

Is your feature request related to a problem? Please describe.

document the perils of merging too quickly

Is your feature request related to a problem? Please describe.

when setting it up i always need to do something like

git config --global user.email "[email protected]"
git config --global user.name "Andrew Lisowski"

it would be way better if those aren't set it tries to set them from package.json/pom.xml/etc.

Right now it basically has all type as possible available. It would be awesome if we could define an interface for each command and get rid of some !s

NOTE: I've spent hours trying to get this to work just right but haven't really gotten close at all

Is your feature request related to a problem? Please describe.

"Something I've been thinking about (and I'm not sure if this is ever a thing we'd support) is the potential for releases that aren't master (or the main branch). Up until this point, we've always assumed that there's 1 path for releases to take -- and they're always linear (using the latest version on npm or github).

What happens in the case of needing to patch a previous release? (1.x has a bug, master is on 2.x but you want to patch 1.x w/ a fix too) If we're going off of the lerna or pkg version I think we'd be okay. The PR lookups would calc a new semver bump and apply that to the version in the current branch.

If we change this to use something outside of the git tree I don't think we'd be able to support that behavior, as there's only ever 1 latest on npm (or wherever we fetch the latest version from)"

~ @adierkens

version:

• We calculate version using the latest release - could this easily switch to the package version?
• The latest release on github might be a problem. I don't think you can actually programmatically set the "Latest Release". So when publishing a patch to 1.x it would become the latest release.

release/changelog

• getCurrentVersion returns lastRelease if gt(lastRelease, lastVersion) - so this would need to be aware of that too

Describe the solution you'd like

We need to depend on latestRelease to be sure that it has a git tag associated with it, so switching isn't an option because we can't be sure that the latest npm version has a tag (like in the thing this issue describes).

I think that we would probably need a new flag that versions from the last git tag. --from-git

With that the release command would probably work. We would have to sort out what the changelog looks like.

the --from-git flag could also override looking at NPM for anything.

Is your feature request related to a problem? Please describe.

I would like to be able to access auto's API like:

const auto = require('auto-release-cli');

Describe the solution you'd like

Just expose it through the package.json

Describe alternatives you've considered

CLI script to initialize auto in your repository

Describe the bug

With an autorc like:

{
  "no-version-prefix": true,
  "onlyPublishWithReleaseLabel": true,
  "name": "Artsy",
  "email": "[email protected]",
  "labels": {
    "major": "Version: Major",
    "minor": "Version: Minor",
    "patch": "Version: Patch",
  },
  "noReleaseLabels": ["Version: Trivial", "Skip Release"]
}

Running yarn auto shipit --verbose gives some of the following output:

~/d/p/a/j/s/reaction-force  $ env GH_TOKEN=xxyyzz yarn auto shipit --verbose                                      master
yarn run v1.12.3
$ /Users/ortatherox/dev/projects/artsy/js/sites/reaction-force/node_modules/.bin/auto shipit --verbose
✔  success   Loaded `auto-release` with config: { 'no-version-prefix': true,
  onlyPublishWithReleaseLabel: true,
  name: 'Artsy',
  email: '[email protected]',
  labels:
   { major: 'Version: Major',
     minor: 'Version: Minor',
     patch: 'Version: Patch' },
  noReleaseLabels: [ 'Version: Trivial', 'Skip Release' ] }
✔  success   Using SEMVER labels:
 { major: 'Version: Major',
  minor: 'Version: Minor',
  patch: 'Version: Patch' }
ℹ  info      Getting repo information from package.json

...
but then later
...


ℹ  info      Adding new changes to changelog.
ℹ  info      Getting commits from v9.1.59 to HEAD
ℹ  info      Calculating SEMVER bump using:
 { labels: [ [], [] ],
  versionLabels:
   Map {
     'major' => 'major',
     'minor' => 'minor',
     'patch' => 'patch',
     'skip-release' => 'skip-release',
     'release' => 'release',
     'prerelease' => 'prerelease',
     undefined => undefined },
  options:
   { onlyPublishWithReleaseLabel: false, skipReleaseLabels: [] } }
✔  success   Calculated SEMVER bump: patch
ℹ  info      Calculated next version to be: 9.1.60
ℹ  info      Old changelog exists, prepending changes.

To Reproduce

See this PR: artsy/reaction#1783 which triggered a minor bump: artsy/reaction@d771f62 and started my digging.

I'm happy to take a look into this tomorrow morning, just wanted to make sure it was fully logged etc (but if you have clues, I'd be ++)

Is your feature request related to a problem? Please describe.

There is currently no way to load any plugins

Describe the solution you'd like

CLI/autorc option plugins is an array of string that either:

• name an included plugin (eg NPM)
• npm package name
• filepath

Is your feature request related to a problem? Please describe.

I want to be able to default documentation to no-release

Describe the bug

is reporting the wrong status on #96

Describe the bug

When i run ship it and an exec function fails the script keeps executing! This makes a lot of problems

Right now it makes you go through each command

Is your feature request related to a problem? Please describe.

Integration tests would really verify that we aren't breaking anything in the product.

Describe the solution you'd like

Here's my plan:

1. Need project to represent the multiple states you can start/continue from
   1. fresh package
   2. Fresh monorepo
   3. Already published + tagged package
   4. Already published + tagged monorepo
   5. Project with messed up latest release
2. Define Fresh Tests
   1. Create Repo
   2. Put simple package in it
   3. Make Pr and merge
   4. Shipit
   5. Ensure GitHub release is correct
   6. Ensure publish to npm
   7. Delete Repo (npm can still be published as we do not check this value. Subsequent test need to check the npm value though so new publishes do not conflict)
3. Define Published Tests
   1. Make Pr and merge
   2. Shipit
   3. Ensure GitHub release is correct
   4. Ensure publish to npm
4. Messed Up
   1. Needs an old release tagged as “latest release” on GitHub
   2. Package.json with a newer version than “latest release”
   3. shipit
   4. Ensure GitHub release is correct
   5. Ensure publish to npm