Skip to content

build: initial release staging script #13621

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

Merged

Conversation

devversion
Copy link
Member

@devversion devversion commented Oct 15, 2018

  • 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.

@devversion devversion 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
@devversion devversion requested a review from jelbourn as a code owner October 15, 2018 19:06
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Oct 15, 2018
@devversion devversion changed the title build: initial release automation script build: initial release staging script Oct 15, 2018
@devversion devversion force-pushed the build/release-automation-script branch from 668a029 to fe35844 Compare October 15, 2018 19:07
* 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
Member

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
Member Author

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
Member

Choose a reason for hiding this comment

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

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

Copy link
Member Author

@devversion devversion Oct 16, 2018

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.


constructor(public projectDir: string) {}

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

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
Member

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) {}
Copy link
Member

@jelbourn jelbourn Oct 16, 2018

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
Member

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:

export function validateExpectedVersion(newVersion: VersionInfo, previous: VersionInfo,
                                        releaseType: ReleaseType): boolean {
  let expectedVersion;
  if (releaseType === 'major') {
    expectedVersion = new VersionInfo(previous.major + 1, 0, 0);
  } else if (releaseType === 'minor') {
    expectedVersion = new VersionInfo(previous.major, previous.minor + 1, 0);
  } else if (releaseType === 'patch') {
    expectedVersion = new VersionInfo(previous.major, previous.minor, previous.patch + 1);
  } else if (releaseType === 'stable') {
    expectedVersion = new VersionInfo(previous.major, previous.minor, previous.patch);
  }
  
  return newVersion.equals(expectedVersion);
}

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

Copy link
Member Author

@devversion devversion Oct 16, 2018

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
Member

Choose a reason for hiding this comment

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

Just Version?

Copy link
Member Author

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
Member

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.

Copy link
Member Author

@devversion devversion Oct 16, 2018

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 Major Minor 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
Member

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
Member

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 devversion force-pushed the build/release-automation-script branch from a1007cc to 4b8738f Compare October 16, 2018 07:54
@@ -63,6 +63,7 @@
"@types/gulp": "3.8.32",
"@types/gulp-util": "^3.0.34",
"@types/hammerjs": "^2.0.35",
"@types/inquirer": "^0.0.43",
Copy link
Member

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
Member Author

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.

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

const newVersion = await promptForNewVersion(this.currentVersion);
Copy link
Member

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
Member Author

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
Member

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
Member Author

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
Member

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.

Copy link
Member Author

@devversion devversion Oct 16, 2018

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.

@googlebot googlebot 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 devversion force-pushed the build/release-automation-script branch from 03fa96e to 48a4edc Compare October 16, 2018 20:08
@googlebot
Copy link

CLAs look good, thanks!

@googlebot googlebot 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
Copy link
Member

@jelbourn jelbourn left a comment

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
Member

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.

@jelbourn jelbourn 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:master Oct 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

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-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: dev-infra Issue related to internal project infrastructure cla: yes PR author has agreed to Google's Contributor License Agreement target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants