Skip to content

build: initial release staging script - #13621

Merged
josephperrott merged 2 commits into
angular:masterfrom
devversion:build/release-automation-script
Oct 17, 2018
Merged

build: initial release staging script#13621
josephperrott merged 2 commits into
angular:masterfrom
devversion:build/release-automation-script

Conversation

@devversion

@devversiondevversion commented Oct 15, 2018

Copy link
Copy Markdown
Member
  • Creates an initial release staging script with prompts.

@jelbourn This is an initial version. There are still a few things like the changelog that I want to address. But those should be additional PRs. -- For now, I've kept the existing Gulp publish stuff until this is finished completely.

@devversiondevversion added area: dev-infra Issue related to internal project infrastructure pr: merge safe target: major This PR is targeted for the next major release labels Oct 15, 2018
@googlebotgooglebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Oct 15, 2018
@devversiondevversion changed the title build: initial release automation scriptbuild: initial release staging scriptOct 15, 2018
@devversion
devversionforce-pushed the build/release-automation-script branch from 668a029 to fe35844CompareOctober 15, 2018 19:07
Comment threadtools/release/git/executor.ts Outdated
* on the working directory of the current process is not good because it's not guaranteed
* that the working directory is always the target project directory (e.g. w/ bazel run).
*/
export class GitCommandExecutor {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe GitClient? "CommandExecutor" makes me think you would pass it full commands to run rather than using API methods directly.

"Executor" also makes me think of something else...

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Ugh haha 😅- GitClient sounds better yeah.


/** Returns the currently checked out branch for the current working directory. */
getCurrentBranch() {
return spawnSync('git', ['symbolic-ref', '--short', 'HEAD'], {cwd: this.projectDir})

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

git name-revmight be better here (?). Or maybe just shorter ¯\(ツ)

@devversiondevversionOct 16, 2018

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

It seems that git name-rev is not returning a short variant of the symbol name.

This is the output: HEAD build/release-automation-script. With symbolic-ref we just get the actual branch name and can read from stdout.

Comment threadtools/release/git/executor.ts Outdated

constructor(public projectDir: string) {}

/** Returns the currently checked out branch for the current working directory. */

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: prefer "Gets ..." to "Returns ..."


if (!currentVersion) {
console.warn(red(`Cannot parse current project version. This means that we cannot validate ` +
`the new ${bold('custom')} version that will be specified.`));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Should we just throw in this case? Why would we ever want to continue if this fails?

public minor: number,
public patch: number,
public suffix?: string,
public suffixNumber?: number) {}

@jelbournjelbournOct 16, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

How about
suffix -> prereleaseLabel
suffixNumber -> prereleaseNumber

A comment that breaks down the different parts would also be good to include here.

newVersion.major === previousVersion.major &&
newVersion.minor === previousVersion.minor &&
newVersion.patch === previousVersion.patch;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

These last four cases could be written a bit more concisely like:

exportfunctionvalidateExpectedVersion(newVersion: VersionInfo,previous: VersionInfo,releaseType: ReleaseType): boolean{letexpectedVersion;if(releaseType==='major'){expectedVersion=newVersionInfo(previous.major+1,0,0);}elseif(releaseType==='minor'){expectedVersion=newVersionInfo(previous.major,previous.minor+1,0);}elseif(releaseType==='patch'){expectedVersion=newVersionInfo(previous.major,previous.minor,previous.patch+1);}elseif(releaseType==='stable'){expectedVersion=newVersionInfo(previous.major,previous.minor,previous.patch);}returnnewVersion.equals(expectedVersion);}

(with the corresponding addition of the equals method on VersionInfo)

@devversiondevversionOct 16, 2018

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

This check is gone completely now.

/** Regular expression that matches version names and the individual version segments. */
const versionNameRegex = /^(\d+)\.(\d+)\.(\d+)(?:-(alpha|beta|rc)\.(\d)+)?$/;

export class VersionInfo {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just Version?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Sounds good.

@@ -0,0 +1,27 @@
import {VersionInfo} from './parse-version';

export type VersionType = 'major' | 'minor' | 'patch';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ReleaseType? A version on its own doesn't inherently have a "type" without the context of the versions around it.

@devversiondevversionOct 16, 2018

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

We already have ReleaseType. A release type can be either: Major Release, Minor Release, Patch Release, Pre-Release, Stable release or Custom release.

Also, isn't each version that follows Semver either MajorMinor or Patch? This is similar to how we have it within the Gulp setup.

I think this is also made clear by the actual Semver rules: e.g. here

* Creates a new version from the specified version based on the given target version type.
* If no target version type has been specified, just the version suffix will be removed.
*/
export function createNewVersion(currentVersion: VersionInfo, targetVersionType?: VersionType):

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there ever a time when the result of this function would be different from expected version for validateExpectedVersion it seems like it could be the same code.

}

return new VersionInfo(
parseInt(matches[1]),

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Prefer Number to parseInt here

@devversion
devversionforce-pushed the build/release-automation-script branch from a1007cc to 4b8738fCompareOctober 16, 2018 07:54
Comment threadtools/release/prompt/new-version-prompt.ts
Comment threadpackage.json
"@types/gulp": "3.8.32",
"@types/gulp-util": "^3.0.34",
"@types/hammerjs": "^2.0.35",
"@types/inquirer": "^0.0.43",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Add an npm scripts alias for stage release that provides the project directory for you?
(might need a small wrapper script)

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Done. We needed a wrapper script because npm scripts do not interpolate environment variables. This should be fine for now.

I will definitely look for ways to improve this, but should be good for an initial implementation.

Comment threadtools/release/prompt/new-version-prompt.ts Outdated
console.log(cyan('-----------------------------------------'));
console.log();

const newVersion = await promptForNewVersion(this.currentVersion);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there anything that validates this new version? Mainly for the case where a custom version is entered.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Yeah, the custom version will be already validated by the validate function which you've simplified with the comment above.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I meant more that the version selected is the correct version, not that it's a valid version. E.g., entering 1.0.0 being incorrect.

This could go in a follow-up, though.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Ah I see, so a custom version can be any valid Semver version that is more recent than the current version right?

Otherwise, if we add more limitations, we could probably remove the "custom-release" once there is a way to create pre-releases with a label

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah, removing it might be better because I can't think of a scenario where you'd want to do something abnormal.

@devversiondevversionOct 16, 2018

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

I agree. I will remove it in the follow-up that will allow creating a pre-release with custom label.

@googlebot

This comment has been minimized.

1 similar comment
@googlebot

This comment has been minimized.

@googlebotgooglebot added cla: no PR author must sign Google's Contributor License Agreement: https://opensource.google.com/docs/cla and removed cla: yes PR author has agreed to Google's Contributor License Agreement labels Oct 16, 2018
* Creates an initial release staging script with prompts.
@devversion
devversionforce-pushed the build/release-automation-script branch from 03fa96e to 48a4edcCompareOctober 16, 2018 20:08
@googlebot

Copy link
Copy Markdown

CLAs look good, thanks!

@googlebotgooglebot added cla: yes PR author has agreed to Google's Contributor License Agreement and removed cla: no PR author must sign Google's Contributor License Agreement: https://opensource.google.com/docs/cla labels Oct 16, 2018

@jelbournjelbourn left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

console.log(cyan('-----------------------------------------'));
console.log();

const newVersion = await promptForNewVersion(this.currentVersion);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I meant more that the version selected is the correct version, not that it's a valid version. E.g., entering 1.0.0 being incorrect.

This could go in a follow-up, though.

@jelbournjelbourn added pr: lgtm action: merge The PR is ready for merge by the caretaker labels Oct 16, 2018
@josephperrott
josephperrott merged commit aaac266 into angular:masterOct 17, 2018
devversion added a commit to devversion/material2 that referenced this pull request Nov 9, 2018
Implements the functionality to select a pre-release label (as discussed in: angular#13621 (comment))
devversion added a commit to devversion/material2 that referenced this pull request Nov 9, 2018
Implements the functionality to select a pre-release label (as discussed in: angular#13621 (comment))
devversion added a commit to devversion/material2 that referenced this pull request Nov 9, 2018
Implements the functionality to select a pre-release label (as discussed in: angular#13621 (comment))
devversion added a commit to devversion/material2 that referenced this pull request Nov 9, 2018
Implements the functionality to select a pre-release label (as discussed in: angular#13621 (comment))
andrewseguin pushed a commit that referenced this pull request Nov 14, 2018
Implements the functionality to select a pre-release label (as discussed in: #13621 (comment))
josephperrott pushed a commit that referenced this pull request Nov 19, 2018
Implements the functionality to select a pre-release label (as discussed in: #13621 (comment))
@angular-automatic-lock-bot

Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-botangular-automatic-lock-botBot locked and limited conversation to collaborators Sep 9, 2019
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: mergeThe PR is ready for merge by the caretakerarea: dev-infraIssue related to internal project infrastructurecla: yesPR author has agreed to Google's Contributor License Agreementtarget: majorThis PR is targeted for the next major release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@devversion@googlebot@jelbourn@josephperrott