Skip to content
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

feat: optionally execute 'git push' during the publish phase #121

Closed
wants to merge 2 commits into from

Conversation

jfairley
Copy link

@jfairley jfairley commented Jan 25, 2019

This is optionally configurable through a new property called 'pushStep', which defaults to 'prepare', but accepts input as 'prepare' or 'publish'.

@pvdlg I intended to write a test to verify that push was called at the correct times, but I'm new to ava, and I didn't see an existing precedent on how to assert that "push" was called. I'll gladly add another test if you could nudge me in the right direction.

This is optionally configurable through a new property called 'pushStep', which defaults to 'prepare', but accepts input as 'prepare' or 'publish'.
@jfairley
Copy link
Author

@pvdlg You know, the more I think about this, the more I realize how useful it would be for my maven workflow to have the whole cycle run on "prepare" and "publish".

The actual JS changes would actually be more elegant, since:

  1. prepare.js could remain completely unchanged, except it'd be appropriate to rename it.
  2. In index.js I could add an async function publish looking much like async function prepare.
  3. Both function prepare and function publish would check the value of context.commitAndPushSteps (see examples below), which would default to 'prepare' for backwards compatibility.

Here's what I'm thinking as far as configuration could look:

module.exports = {
	plugins: [
		// prepare: bump maven version to `nextRelease.version`
		// publish: 1. build and deploy artifacts
        // publish: 2. bump maven version to the next snapshot version
		'semantic-release-maven',
		['@semantic-release/git', {
			assets: ['pom.xml'],
			// this is optional and defaults to 'prepare' (preserving backwards compatibility)
			commitAndPushSteps: ['prepare', 'publish']
		}]
	]
};

The only thing I'm stuck on with ^^^ solution is reusing the same message...

So, here I have a semantic-release question: Is the context mutable and shared between plugins? What if in my custom plugin I set context.mavenVersion = '1.2.3'? That could allow something like:

module.exports = {
	plugins: [
		'semantic-release-maven',
		['@semantic-release/git', {
			assets: ['pom.xml'],
			message: 'chore(release): ${mavenVersion} [skip ci]',
			commitAndPushSteps: ['prepare', 'publish']
		}]
	]
};

Or something else I've been chewing on is declaring the git plugin twice, but again, is this possible? If so I could do something like:

module.exports = {
	plugins: [
		['@semantic-release/git', {
			assets: ['pom.xml'],
			commitAndPushSteps: ['prepare']
		}],
		'semantic-release-maven',
		['@semantic-release/git', {
			assets: ['pom.xml'],
			message: 'chore(release): incrementing to next development snapshot [skip ci]',
			commitAndPushSteps: ['publish']
		}]
	]
};

If any of this is confusing, I'll gladly push up a separate PR to illustrate the code changes... In fact, I might do it anyway, since the changes ought to be pretty easy...

@jfairley
Copy link
Author

jfairley commented Jan 25, 2019

And yet another hair-brained configuration idea...

module.exports = {
	plugins: [
		'semantic-release-maven',
		['@semantic-release/git', {
			prepare: {
				assets: ['pom.xml']
			},
			publish: {
				assets: ['pom.xml'],
				message: 'chore(release): incrementing to next development snapshot [skip ci]'
			}
		}]
	]
};

Obviously, even in this scenario, doing the standard configuration, would apply the data to "prepare", and "publish" would not happen unless specified. ⬇️

module.exports = {
	plugins: [
		// ... a bunch of standard plugins,
		['@semantic-release/git', {
			assets: ['package.json', 'package-lock.json']
		}]
	]
};

@jfairley
Copy link
Author

jfairley commented Feb 4, 2019

I closed this for clarity. I prefer and put more work into #122.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant