intuit / auto Goto Github PK
View Code? Open in Web Editor NEWGenerate releases based on semantic version labels on pull requests.
Home Page: https://intuit.github.io/auto/
License: MIT License
Generate releases based on semantic version labels on pull requests.
Home Page: https://intuit.github.io/auto/
License: MIT License
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.
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 ++)
sounds better
look at the changelog
Right now it makes you go through each command
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.
Describe the bug
is reporting the wrong status on #96
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
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:
NPM
)Is your feature request related to a problem? Please describe.
how do you use auto-release without the CLI
Use the platform!
Is your feature request related to a problem? Please describe.
I want to be able to default documentation
to no-release
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.
"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)"
version:
version
using the latest release - could this easily switch to the package version?release/changelog
getCurrentVersion
returns lastRelease if gt(lastRelease, lastVersion) - so this would need to be aware of that tooDescribe 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 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
look at 0.36.3
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:
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.
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.
document the perils of merging too quickly
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:
need to figure out interop with plugins
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.
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.
Is your feature request related to a problem? Please describe.
There are a few pitfalls that need documentation.
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
auto shipit
when an npm package fails to be published
Expected behavior
CI Task fails appropriately
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
Add some docs/examples around the .autorc file. It's referenced in the docs, but not really an example anywhere
CLI script to initialize auto in your repository
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.
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.
Integration tests would really verify that we aren't breaking anything in the product.
Describe the solution you'd like
Here's my plan:
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.
use the platform!
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.
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
Describe the bug
When i run ship it and an exec function fails the script keeps executing! This makes a lot of problems
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
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
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.
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.