Finish everything up

[niklashigi]

The core functionality is now implemented, but there's still a lot to do:

• Implement missing tests (help on this would be appreciated)
• Decide how users should install apm (atom-package-manager) on their build server
• Move this repository into the @semantic-release organization (definitely need help on this)
• Setup TravisCI, Codecov and Greenkeeper (once the repository has been moved)
• Add documentation to the main repository's README on how to use semantic-release with apm
• Other things I've missed

Tagging @pvdlg and @gr2m for feedback and help.

[pvdlg]

I never used apm and I don't know their architecture. But I can help with the rest.

Implement missing tests (help on this would be appreciated)

Could you be more specific? Is it an issue related to using ava? Or how to implement a specific test?
If it's related to the integration test (similar to what we do with https://github.com/npm/npm-docker-couchdb) I'm not really sure how to have an equivalent for apm.
It seems apm is based on npm, so maybe the registry is the same and npm-docker-couchdb would work? I'd suggest to look for solutions to install an apm registry locally.

Decide how users should install apm (atom-package-manager) on their build server

If a binary as to be installed, I think it's out of the scope of sematic-release. With npmwe call the CLI withexecato make the release because there is no good API client (the release code is partially innpmitself and innpm/npm-registry-client). Maybe for apmthe ecosystem is a bit better and there is a node package that you can use to make a release, instead of calling theapmCLI. That would probably avoid several potential issue, such as a missingapm` binary or a different version that is not test with your code.

[niklashigi]

Could you be more specific? [...] If it's related to the integration test [...].

Yes, it's related to the integration test. Since I still haven't quite understood how apm works aside from the REST API and have zero experience with integration testing, I have no clue how to tackle it.

If a binary has to be installed, I think it's out of the scope of semantic-release.

Yes, I think so too. The apm binary, fortunately, is available on npm as atom-package-manager. Should I add it as a dependency and use the binary from the node_modules folder? Or require it as a peer dependency?

[pvdlg]

Yes, it's related to the integration test. Since I still haven't quite understood how apm works aside from the REST API and have zero experience with integration testing, I have no clue how to tackle it.

I don't know either. Maybe you can try with https://github.com/npm/npm-docker-couchdb ? Maybe with http://www.mock-server.com/ (I use it in semantic-release to simulate Github)? Or simply with https://github.com/node-nock/nock if you mange to make all the calls to the APM registry with JS API.

The apm binary, fortunately, is available on npm as atom-package-manager.

According to https://github.com/atom/ci it seems that running apm on a CI server is a bit more complicated than just having the apm binary installed and running a command. It seems users would have to install a bunch of stuff anyway. So it's probably better to just check that what you need is there (Token, apm binary, other things you use in the plugin) and not add it as a dependency.

[pvdlg]

Also while Googling I found https://github.com/Adezandee/last-release-apm
Are you aware of this plugin? Maybe you can join efforts with its author?

[niklashigi]

Also while Googling I found Adezandee/last-release-apm
Are you aware of this plugin? Maybe you can join efforts with its author?

I wasn't aware of it so far, but I was able to get some inspiration from it like how to get the Git head of the last release (0ad0056). However, I'm not thinking about joining efforts with the author because that would probably become quite complicated communication-wise.

[pvdlg]

like how to get the Git head of the last release (0ad0056).

For information, if the getLastRelease function doesn't returns a gitHead (only a version), then semantic-release will take care of figuring out the gitHead for you based on the repo tags.
See get-commits.js#L52.

So if you retrieve the gitHead only based on a git tag, that unnecessary, you can return only a version and semantic-release will do the rest.
If the retrieval of the gitHead is more complex and specific to apm then you should return it.

[niklashigi]

you can return only a version and semantic-release will do the rest.

Okay, I removed the commit.

---

I also investigated what exactly apm publish does. It ...

• checks whether --version was specified and runs npm version patch if it is missing ⚠️
• registers the package using the Atom API if it wasn't already registered
• renames the package using the Atom API if --rename was specified
• creates a new Git tag for the new version and pushes it to GitHub ⚠️
• waits for the Git tag to be available through the GitHub API by checking repeatedly
• registers the new version with a POST request to the Atom API

The two steps marked with ⚠️ make me wonder: Isn't that semantic-release's job?
The first one can be solved by calling it with --version the.new.version, but the second one?

This also makes me think that we only need to mock the Atom and the GitHub API since there's no actual npm registry involved.

[pvdlg]

The first one can be solved by calling it with --version the.new.version

Yes that's the good solution

but the second one?

I think the best approach for this type of situation will be for plugins to check if the tag already exist (the github plugin should do at some point I think).
What happen if the tag already exists ? Does it fails ? Do it just use the existing tag ? Recreate one?

This also makes me think that we only need to mock the Atom and the GitHub API since there's no actual npm registry involved.

My understand is that the Atom API is actually an NPM registry. Maybe a customized one. Which is why I mentionned https://github.com/npm/npm-docker-couchdb. But I might be wrong

[niklashigi]

My understanding is that the Atom API is actually an NPM registry.

I just tested a few things and found that ...

• https://registry.npmjs.com/packages returns a similar response to https://atom.io/api/packages
• but https://registry.npmjs.com/packages/semantic-release responds with a 404 error while https://atom.io/api/packages/teletype returns the data about a package

I also don't think it's an npm registry because of one major difference: apm is dependent on GitHub and mirrors/proxies the release tarballs generated by it. You cannot upload files to apm like you can with npm.

---

I also just found out that it's possible to specify a --tag for apm publish, so I should be able to do:

execa('apm', ['publish', '--tag', 'v' + nextRelease])

Right? Has semantic-release already pushed the version tag to GitHub at this point?

[pvdlg]

From publish.coffee#L33

If a new version or version increment is specified, then a new Git tag is created and the package.json file is updated with that new version before it is published to the apm registry. The HEAD branch and the new tag are pushed up to the remote repository automatically using this option.

So you should just do write the version in the package.json the same it's done in the npm plugin and run execa('apm', ['publish']). This way no tag will be created.

I also don't think it's an npm registry because of one major difference: apm is dependent on GitHub and mirrors/proxies the release tarballs generated by it. You cannot upload files to apm like you can with npm.

They mention apm#relation-to-npm that they bundle npm so I assumed the registry would be the same.
Not sure what's the best solution is for integration tests. Maybe something with MockServer like test/helpers/mockserver.js

[niklashigi]

I just experimented a bit with apm and found out a few new things (including the fact that apm publish doesn't work without arguments): https://asciinema.org/a/GckKLDSeozhvBjO1wuyNkiNE6

This brings up a few new questions:

• Should the plugin handle changing the version field and creating the tag or should apm do that?
• How can we give the CI server the permission to git push to the repository? And under whose name should the server commit that (@semantic-release-bot or custom name and email)?
• How do we prevent that commit from triggering another build? [skip ci]/the current CI's equivalent?

[niklashigi]

@pvdlg Any thoughts on this? ⬆️

[pvdlg]

Sorry I missed your previous message.

Should the plugin handle changing the version field and creating the tag or should apm do that?

Can you confirm that if you run apm publish --tag x.x.x apm will not try to create the tag and not create a Prepare... commit?
If yes that's good news! The git tag you have to use is passed by semantic-release in nextRelease.gitTag so you can use that.

What happen if the tag doesn't exists and you run apm publish --tag vx.x.x ?

If the tag need to exists for apm publish --tag vx.x.x then you would have to:

• Verify if the tag exists with something like that
• If it does exists, then calls apm publish --tag vx.x.x
• If it doesn't exists you'll have to create it and then call apm publish --tag vx.x.x. I'm going to release a git plugin soing something similar. I'll give you a code example when I release it.

Ideally we would have something like that:

1. If the user use the git plugin and apm plugin

• The git plugin will create the tag and make a commit that include the package.json and a CHANGELOG.md
• The apm plugin will call apm publish --tag x.x.x. No tag is created by apm not the apm plugin. The package is published on apm registry.

2. If the user use only the apm plugin:

• The apm plugin will detect the tag is not there, creates it and push. Then calls apm publish --tag x.x.x. The package is published on apm registry.

How can we give the CI server the permission to git push to the repository? And under whose name should the server commit that (@semantic-release-bot or custom name and email)?

I'll give you an example when I release the git plugin. It's possible only if you control the git push command. This is why you have to create the tag yourself rather than letting apm do it (as it will fail due to missing authentication).

How do we prevent that commit from triggering another build? [skip ci]/the current CI's equivalent?

Yes, all CI I'm aware of accept [skip ci]. Example to come with the git plugin as well.

[niklashigi]

Can you confirm that if you run apm publish --tag x.x.x apm will not try to create the tag and not create a Prepare... commit?

I just tried something and am very confused. Is this apm's or my fault?

[pvdlg]

The error come from here.

It seems apm publish to the repository, then the repository check for the tag existence on Github and respond. Maybe it takes a few seconds for Github to make the tag available....and this is why apm is doing this loop to check if the tag has been created...

Can you try the same thing, but wait like 15-10 second between the git push and the apm publish ?

[niklashigi]

I tried it again just now, the tag still can't be found ...

[pvdlg]

That's really weird...Maybe open a bug with apm?
I really don't see why it wouldn't find the tag....

[niklashigi]

The issue I opened has now been resolved.

---

Can you confirm that if you run apm publish --tag x.x.x apm will not try to create the tag and not create a Prepare... commit?

Since it works now, yes. apm will not create a commit, it will just check whether the tag exists and then add it to the registry.

[niklashigi]

I just wanted to try to publish my semantic-release-apm-example package with semantic-release and the current version of the plugin. So I ...

• symlinked to semantic-release-apm to node_modules/@semantic-release/apm
• configured semantic-release in the package.json like this:

"release": {
  "verifyConditions": ["@semantic-release/apm"],
  "verifyRelease": ["@semantic-release/apm"],
  "getLastRelease": ["@semantic-release/apm"],
  "publish": ["@semantic-release/apm"]
}

• exported both GH_TOKEN and APM_TOKEN
• and ran npm run build (semantic-release --debug=false) which gave me the following error:

semantic-release WARN invalid config loglevel="notice"
semantic-release ERR! init No github token specified. ENOGHTOKEN
semantic-release ERR! init No npm token specified. ENONPMTOKEN
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! semantic-release-apm-example@1.9.0 release: `semantic-release --debug=false`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the semantic-release-apm-example@1.9.0 release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging
         output above.

@pvdlg Is there anything I forgot to configure or is it currently impossible to not use npm at all?

[pvdlg]

It seems you are using an old version of semantic-release. You should specify version ^11.0.0 in your package.json

[niklashigi]

You should specify version ^11.0.0 in your package.json

Did that. Running semantic-release --debug=false now returns the usage infomation, do I have to add something to the command?

[pvdlg]

The logs you have listed definitely come from an old version. I guess you are using the globally install version which is old.

[niklashigi]

With "Did that." I meant that I now use the new version. I just changed it.

I guess you are using the globally install version which is old.

I run semantic-release using an npm script, so it should (now) use the correct version (v11.0.1).

[pvdlg]

--debug is now a way to print additional infos. If you don't want debug info then don't use the --debug options. If you want the debug info then just use --debug not debug=<value>

[niklashigi]

I just the command and got this error:

[Semantic release]: Load plugin @semantic-release/apm
[Semantic release]: Load plugin @semantic-release/apm
[Semantic release]: Load plugin @semantic-release/commit-analyzer
[Semantic release]: Load plugin @semantic-release/release-notes-generator
[Semantic release]: Load plugin @semantic-release/apm
[Semantic release]: Run automated release from branch master
[Semantic release]: Call plugin verify-conditions
[Semantic release]: An error occurred while running semantic-release: TypeError [ERR_INVALID_ARG_TYPE]: The "last argument" argument must be of type function
    at verifyConditions (util.js:1086:13)
    at /mnt/data/GitHub/semantic-release-apm-example/node_modules/semantic-release/lib/plugins/normalize.js:27:26
    at pReduce (/mnt/data/GitHub/semantic-release-apm-example/node_modules/semantic-release/lib/plugins/pipeline.js:10:28)
    at Promise.all.then.value (/mnt/data/GitHub/semantic-release-apm-example/node_modules/p-reduce/index.js:16:10)
    at <anonymous>

This is weird since semantic-release no longer uses callbacks.

[pvdlg]

This is because your code use callback: https://github.com/shroudedcode/semantic-release-apm/blob/master/index.js#L31

[niklashigi]

This is because your code use callback:

Oops ... that happens when you clone someone's repository and not look at all of the code before making changes. Fixed that now.

---

The problem I'm having now is the following:

[Semantic release]: There is no previous release, the next release version is 1.0.0
[Semantic release]: Call plugin verify-release
[Semantic release]: Call plugin generateNotes
[Semantic release]: Call plugin publish
[Semantic release]: Wrote version 1.0.0 to package.json
[Semantic release]: Publishing version 1.0.0 to apm registry

I logged the result of getLastRelease() and it was { version: '1.9.0' } ...

[pvdlg]

Maybe you have a v1.0.0 and a v1.9.0 tag both pointing to the branch head

[niklashigi]

Maybe you have a v1.0.0 and a v1.9.0 tag both pointing to the branch head

They point to different commits ... is that what you meant?

[pvdlg]

If they reference different commits, it shouldn't be a problem. I don't know why 1.0.0 is written to you package.json then...

[niklashigi]

I've deleted, unpublished and recreated the example repository and tried to run semantic-release again:

> semantic-release-apm-example@1.0.0 release /mnt/data/GitHub/semantic-release-apm-example
> semantic-release

[Semantic release]: Load plugin @semantic-release/apm
[Semantic release]: Load plugin @semantic-release/apm
[Semantic release]: Load plugin @semantic-release/commit-analyzer
[Semantic release]: Load plugin @semantic-release/release-notes-generator
[Semantic release]: Load plugin @semantic-release/apm
[Semantic release]: Run automated release from branch master
[Semantic release]: Call plugin verify-conditions
[Semantic release]: Logging in with atom.io API token
[Semantic release]: Call plugin get-last-release
[Semantic release]: No version of package semantic-release-apm-example found
[Semantic release]: No previous release found, retrieving all commits
[Semantic release]: Found 2 commits since last release
[Semantic release]: Call plugin analyze-commits
[Semantic release]: Analyzing commit: fix(readme): remove test text
[Semantic release]: The release type for the commit is patch
[Semantic release]: Analyzing commit: Initial commit
[Semantic release]: The commit should not trigger a release
[Semantic release]: Analysis of 2 commits complete: patch release
[Semantic release]: There is no previous release, the next release version is 1.0.0
[Semantic release]: Call plugin verify-release
[Semantic release]: Call plugin generateNotes
[Semantic release]: Call plugin publish
[Semantic release]: Wrote version 1.0.0 to package.json
[Semantic release]: Publishing version 1.0.0 to apm registry
[Semantic release]: An error occurred while running semantic-release: { Error: Command failed: /bin/sh -c apm publish --tag v1.0.0
npm WARN invalid config loglevel="notice"
Creating new version failed: Git tag not found

Publishing semantic-release-apm-example@v1.0.0 ✗

    at Promise.all.then.arr (/mnt/data/GitHub/apm/node_modules/execa/index.js:236:11)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: 1,
  killed: false,
  stdout: 'Publishing semantic-release-apm-example@v1.0.0 \u001b[31m✗\n\u001b[39m',
  stderr: 'npm WARN invalid config loglevel="notice"\n\u001b[31mCreating new version failed: Git tag not found\u001b[39m\n',
  failed: true,
  signal: null,
  cmd: '/bin/sh -c apm publish --tag v1.0.0',
  timedOut: false }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! semantic-release-apm-example@1.0.0 release: `semantic-release`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the semantic-release-apm-example@1.0.0 release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

It now fails because APM can't find the tag (which was to expect). @pvdlg, how can I modify the config to make semantic-release create and push the tag? Do I have to use the git or github plugin?

[pvdlg]

I would suggest to either let apm to create the tag, or doing in the plugin before calling apm. You can find examples in the git plugin.

It would probably be problematic to have your plugin relying on another one, as if users do not use that plugin you are relying on it would fail.

If I remember well, apm called without --tag would create the tag, and it would expect it wuen used with --tag?
So you could check if the tag already exist, and if it does call amp publish --tag vx.x.x and if it doesn't call apm publish?

[niklashigi]

If I remember well, apm called without --tag would create the tag, and it would expect it when used with --tag?

Running apm without --tag returns:

A version, tag, or new package name is required

Running apm with a version – in this case apm publish 1.0.1 – returns:

Preparing and tagging a new version ✓
Pushing v1.0.1 tag Username for 'https://github.com':

It prompts you to enter your GitHub username and password. Then it creates a Prepare X.Y.Z release commit (in which it changes the version in the package.json), adds the version tag, pushes both of them and then calls the atom.io API to register the release.

---

While it seems like the easiest solution would be to just run apm publish <Version>, doing that also has some problems like ...

• an uncustomizable commit message (Preparing X.Y.Z release)
• no easy way ([skip ci]) to prevent an unnecessary CI build from being triggered
• weird authentication behavior (GitHub login prompt although git push works without that)

The other option would be to manually ...

• change the version in the package.json to the new version
• commit that change and add [skip ci] to the commit message
• correctly tag that commit
• set the URL of the origin to use the GitHub token (https://username:token@github.com/username/repo.git)
• git push && git push --tags
• wait for the tag to be available
• run apm publish --tag <Tag>

@pvdlg What do you think?

[pvdlg]

This apm command behavior is tricky...

Is doing the commit necessary for apm packages to work?
It seems the commit is done in order to push the updated package.json to the repository. But is it necessary for atom packages ? I'm not sure if packages are downloaded from the repo itself or from some sort of repository.

[niklashigi]

Is doing the commit necessary for apm packages to work?

Creating new version failed: You specified a tag with the version number '1.0.4',
but the version number in package.json is '1.0.3'. The version numbers must agree before
you can publish.

So, yes.

---

I'm not sure if packages are downloaded from the repo itself or from some sort of repository.

They are downloaded from the repository, atom.io only serves as a proxy. Quote from a GitHub employee on an issue regarding package download problems that explains this:

At this point ☝️, when someone runs apm install ghar-syntax, apm tries to fetch the tarball for repository ID 60258912 on github.com, but no such repository exists.

[pvdlg]

So, yes.

That's going to make things very tricky then as you will need write access to the repo to make the commit, which is not necessary easy on a CI. You can see all the shenanigans I'm doing on the git plugin.

I think you can model a lot of the plugin after the git plugin:

• Same handling of repo authentication (And SSH and GPG keys if you'd like to)
• Same handling of creating the tag if doesn't exist, delete the tag in case it was previously created without the info added by apm
• Then you decide if you prefer doing the commit and the tag yourself or let apm doing it

Check this part of the git plugin.

Another entirely different solution:

• Use the git plugin to create the tag and the commit that includes the updated package.json
• Use the exec plugin to run apm publish <version> --tag <tag>

That would mean there is no need for a specific apm plugin. I didn't put too much though on it, and I'm not sure it would work, but it worth to try I think.
The config would look like that:

{
  "release": {
    "verifyConditions": ["@semantic-release/condition-travis", "@semantic-release/git", "@semantic-release/github"],
    "getLastRelease": "@semantic-release/git",
    "publish": [
      {
        "path": "@semantic-release/git",
        "assets": ["package.json"],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }, 
      {
        "path": "@semantic-release/exec",
        "cmd": "apm publish ${nextRelease.version} --tag ${nextRelease.gitTag}",
      },
      "@semantic-release/github"
    ]
  }
}

I'm not sure if the github plugin is necessary as apm might already create the Github release?. You might have to customize the assets property if there is more than the package.json to commit.

The exec plugin is not released yet but you can add it to your dependencies like that:

"@semantic-release/exec": "semantic-release/exec#initial-release"

[niklashigi]

@pvdlg The solution you suggested seems to work until apm publish is called and complains about the "download from GitHub version" of @semantic-release/exec.

> semantic-release-apm-example@1.0.3 release /mnt/data/GitHub/semantic-release-apm-example
> semantic-release

[Semantic release]: Load plugin @semantic-release/git
[Semantic release]: Load plugin @semantic-release/github
[Semantic release]: Load plugin @semantic-release/git
[Semantic release]: Load plugin @semantic-release/commit-analyzer
[Semantic release]: Load plugin @semantic-release/release-notes-generator
[Semantic release]: Load plugin @semantic-release/git
[Semantic release]: Load plugin @semantic-release/exec
[Semantic release]: Load plugin @semantic-release/github
[Semantic release]: Run automated release from branch master
[Semantic release]: Call plugin verify-conditions
[Semantic release]: Verify authentication for repository git+https://github.com/shroudedcode/semantic-release-apm-example.git
[Semantic release]: Verify Github authentication
[Semantic release]: Call plugin get-last-release
[Semantic release]: Found git tag version v1.0.4
[Semantic release]: Retrieving commits since v1.0.4, corresponding to version 1.0.4
[Semantic release]: Found 1 commits since last release
[Semantic release]: Call plugin analyze-commits
[Semantic release]: Analyzing commit: fix(release): try using the git plugin to publish
[Semantic release]: The release type for the commit is patch
[Semantic release]: Analysis of 1 commits complete: patch release
[Semantic release]: The next release version is 1.0.5
[Semantic release]: Call plugin verify-release
[Semantic release]: Call plugin generateNotes
[Semantic release]: Call plugin publish
[Semantic release]: Creating tag v1.0.5
[Semantic release]: Published Git release: v1.0.5
[Semantic release]: Call script apm publish 1.0.5 --tag v1.0.5
The @semantic-release/exec dev dependency range in the package.json file is invalid: semantic-release/exec#initial-release
[Semantic release]: An error occurred while running semantic-release: { Error: Command failed: /bin/sh -c apm publish 1.0.5 --tag v1.0.5
The @semantic-release/exec dev dependency range in the package.json file is invalid: semantic-release/exec#initial-release


    at Promise.all.then.arr (/mnt/data/GitHub/semantic-release-apm-example/node_modules/execa/index.js:236:11)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: 1,
  killed: false,
  stdout: '',
  stderr: '\u001b[31mThe @semantic-release/exec dev dependency range in the package.json file is invalid: semantic-release/exec#initial-release\u001b[39m\n',
  failed: true,
  signal: null,
  cmd: '/bin/sh -c apm publish 1.0.5 --tag v1.0.5',
  timedOut: false }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! semantic-release-apm-example@1.0.3 release: `semantic-release`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the semantic-release-apm-example@1.0.3 release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

[pvdlg]

It seems apm prevent to release with a package.json that reference a repo directly.
I just released the exec plugin so you should be able to reference it normally in your dependencies.

[niklashigi]

I just released the exec plugin so you should be able to reference it normally in your dependencies.

Awesome! 😸

---

The problem now is that semantic-release doesn't change the version in the package.json, so no commit is created.

[Semantic release]: Call script apm publish --tag v1.0.7
npm WARN invalid config loglevel="notice"
Publishing semantic-release-apm-example@v1.0.7 ✗
Creating new version failed: You specified a tag with the version number '1.0.7', but the version number in package.json is '1.0.6'. The version numbers must agree before you can publish.
[Semantic release]: An error occurred while running semantic-release: { Error: Command failed: /bin/sh -c apm publish --tag v1.0.7
npm WARN invalid config loglevel="notice"
Creating new version failed: You specified a tag with the version number '1.0.7', but the version number in package.json is '1.0.6'. The version numbers must agree before you can publish.

Publishing semantic-release-apm-example@v1.0.7 ✗

    at Promise.all.then.arr (/mnt/data/GitHub/semantic-release-apm-example/node_modules/execa/index.js:236:11)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: 1,
  killed: false,
  stdout: 'Publishing semantic-release-apm-example@v1.0.7 \u001b[31m✗\n\u001b[39m',
  stderr: 'npm WARN invalid config loglevel="notice"\n\u001b[31mCreating new version failed: You specified a tag with the version number \'1.0.7\', but the version number in package.json is \'1.0.6\'. The version numbers must agree before you can publish.\u001b[39m\n',
  failed: true,
  signal: null,
  cmd: '/bin/sh -c apm publish --tag v1.0.7',
  timedOut: false }
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! semantic-release-apm-example@1.0.6 release: `semantic-release`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the semantic-release-apm-example@1.0.6 release script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

[pvdlg]

Ah yeah...
Can you try with this config:

{
  "release": {
    "verifyConditions": ["@semantic-release/condition-travis", "@semantic-release/npm", "@semantic-release/git", "@semantic-release/github"],
    "getLastRelease": "@semantic-release/git",
    "publish": [
      {
         "path": "@semantic-release/npm",
          "npmPublish": false
     }, 
     {
        "path": "@semantic-release/git",
        "assets": ["package.json"],
        "message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
      }, 
      {
        "path": "@semantic-release/exec",
        "cmd": "apm publish ${nextRelease.version} --tag ${nextRelease.gitTag}",
      },
      "@semantic-release/github"
    ]
  }
}

You might have to set up an NPM_TOKEN for now to pass the validation. I'll push a PR soon to not verify the token when npmPublish is false.

[niklashigi]

Yes, it works! 🎉

But this solution uses too many (mostly unused) plugins and too much configuration. Putting only the code that's needed for it to work into a separate package would be much better.

Could you maybe do that? You've developed/contributed to all four of them, so it should a lot easier for you.

[pvdlg]

But this solution uses too many (mostly unused) plugins and too much configuration

All the plugin are used. Also we are going to support shareable config soon: semantic-release/semantic-release#553

Maybe I can create a @semantic-release/apm-config that would contain this config.

I'm not so sure about creating an apm plugin that would 90% similar to other plugin, as it would just create more code to maintain and every modification to one of those plugin would have to be ported to the apm plugin.

What do you think about @semantic-release/apm-config?
You would configure your project like that:

"release": {
  "extends": "@semantic-release/apm-config"
}

[niklashigi]

All the plugin are used.

I know. What I meant was that most of the code of these plugins is not used, because we only use certain features of them.

What do you think about @semantic-release/apm-config?

That would certainly make it easier to use, but there's still a lot of unnecessary code being downloaded and everyone using it would have to manually install all of the necessary plugins.

[pvdlg]

That would certainly make it easier to use, but there's still a lot of unnecessary code being downloaded and everyone using it would have to manually install all of the necessary plugins.

Yes and no. Most of the plugin used are already there as they are dependencies of semantic-release. You wouldn't have to add any plugin as dependency as @semantic-release/apm-config would take care of that. The only dependency you need are @semantic-release/apm-config and semantic-release.

Regarding unused code, I don't think it's really a problem. You'd end up with a few bytes or kilobytes more in your node_modules. This kind of things happen all the time, for example if you use only some function provided by any module you are depending on.

In addition, having a few additional bytes/kilobytes in your node_modules is probably a better trade of if you compare to maintaining an additional plugin with code duplication.

[niklashigi]

In addition, having a few additional bytes/kilobytes in your node_modules is probably a better trade of if you compare to maintaining an additional plugin with code duplication.

Got it. Let's make @semantic-release/apm-config happen.

[pvdlg]

I'm going to look into it. Ideally I'd like to use it to make a good and comprehensive example of a shareable config, so folks could fork it to make other shareable configs. I'll keep you posted and ask for help/feedback.

It was nice to work with you and experiment around apm. A lot of what happened in this issue had an influence on the choices we made for semantic-release. So it might not ends up with a plugin being released, but it really achieved a lot in terms of moving semantic-release forward. So thanks a lot!

[niklashigi]

So thanks a lot!

Thanks a lot for helping me with this, just mention me if you need feedback or help! 🐱