Fetch release-please manifest and config files from changes-branch #31
Conversation
|
That will benefit both Stainless CI (Robert faced this issue) and the GitHub App (that's where I personally faced the issue when running against my freshly created test repo). |
|
You can see the generated PR here: DefinitelyATestOrg/sdk-node#1 |
…ven that's Stainless default behaviour
| @@ -751,7 +752,7 @@ If you instead want to use the version number \`${newVersion}\` generated from c | |||
| return Version.parse(this.initialVersion); | |||
| } | |||
|
|
|||
| return Version.parse('1.0.0'); | |||
| return Version.parse('0.0.1'); | |||
There was a problem hiding this comment.
That's more in line with initial version numbers Stainless uses.
| protected initialReleaseVersion(): Version { | ||
| return Version.parse('0.1.0'); | ||
| } |
There was a problem hiding this comment.
Not sure why the initial version number is different for different languages? That's kind of odd and doesn't match Stainless behaviour.
|
@RobertCraigie Unless that's blocking you I will wait for Marcel to be able to review before merging. Just in case he disagrees or has some feedback. Edit: it's not a blocker for my own work, I just updated my stuff to target this branch. |
When using release-please with
--change-branch=nextagainst a new repository where no manifest or config has been merged tomainyet, we get an error:My test repositor has a
nextbranch with a manifest, but no release has been created yet, somainis just an "Initial commit".The way upstream release-please generally work is that a
release-please bootstrapcommand is first run to generate a default manifest and config. But in the context of Stainless that step isn't necessary, content pushed tonextwill always have release-please config files, we just need to be surerelease-pleaseis looking at the correct branch. Given thatnextis always supposed to be based on top ofmainwe can consider its manifest as up to date.