git submodules

[tomdavidson]

Should checked out submodules be included in the release?

[stevemao]

monorepo probably works better for you? See

https://github.com/lerna/lerna#--conventional-commits

[tomdavidson]

Thanks but not quite. It is not a mono repo just needs a git submodule to be complete. I see that isn't normal for GitHub but was hoping for undocumented config options. May need to rethink the submodule or make the release with a custom script.

[stevemao]

I don't know how it works with submodules. How you'd group commits between the modules? You could make a release in the submodule and in your main repo your related commits can reference it?

There are a few alternatives to submodules. One of them and probably works the best in most cases is monorepo. I was wondering if you could switch to that.

[hutson]

Also, just a side note, but depending on the need to support submodules, it may be more appropriate to move this discussion to conventional-changelog since conventional-github-releaser does nothing more than get a changelog, generated by conventional-changelog, and posts it to a GitHub Release page.

[tomdavidson]

Ah I see a misunderstanding. In this issue I'm looking for the submodule being included in the release assets not anything to do with gathering the submodule commit messages. It looks like the lib does not create its own archive .

Any thoughts on tar/zip the cwd and posting that asset - this would include the submodule as long as it was checkout?

[stevemao]

I don't use the downloads on github releases. It might be a feature for github to concern. I'd still use monorepo in this case so that all the source code is available on github releases.
I also suggest you to use npm to manage the dependencies instead of submodules if they are not highly coupled.

[hutson]

In this issue I'm looking for the submodule being included in the release assets not anything to do with gathering the submodule commit messages.

@tomdavidson thank you for the clarification. We were definitely on different pages. 😄

You are entirely correct in your statement; conventional-github-releaser does not post archive files to a GitHub release page.

conventional-github-releaser could publish archive files to a release, but we would need to determine what the user actually wants to archive.

For example, since I use this project to release npm packages, I've thought of uploading the artifact that is published to the npm registry using npm publish. That archive file would be a subset of my working directory.

However, in your case, you would want to publish everything under the current working directory (including git submodules).

In that very specific case, I think @stevemao is correct in that GitHub should provide support for downloading all source code, including any referenced git submodules. They already provide a download link for the source code, and I don't see how we can provide a better experience than what they could achieve.

If you would like us to discuss how we can support uploading arbitrary artifacts, we can move forward with that discussion, though that probably needs to happen on a new issue where we can start fresh on the new topic.

[tomdavidson]

My itch would be scratch with the archive that npm publish gives.

But sometimes one will not want to publish deployables despite wanting a github release (on a private repo). So could you use npm publish but still respect (package.json).private ?

[stevemao]

@tomdavidson You might want to look at private npm repository.

[stevemao]

@hbetts I think pushing artifacts is a very good idea. I just don't know how much demand we have for it.

[hutson]

I just don't know how much demand we have for it.

This is the first case I have seen related to a conventional-changelog project, though I do use quite a few projects that publish their build artifacts through GitHub, so perhaps there is an undercurrent within the software community that could use such a feature from conventional-github-releaser.

My suggestion would be to package the publishing functionality as a separate tool that can be called after conventional-github-releaser has finished.

My reasoning is that, what we can publish as an artifact can not be determined by conventional-github-releaser. Though we are talking about publishing the results of npm pack, perhaps I may also want to publish an executable using the tool pkg? Perhaps others will want to use conventional-github-releaser for publishing artifacts from other languages?

Therefore, a separate tool, perhaps called github-publish-npm-tarball, may be a more appropriate setup. Then those who want to publish npm pack results to GitHub just need to install the extra tool and call it with the latest git tag.

[hutson]

Closing this issue out.

@tomdavidson please feel free to open an issue on conventional-changelog and the conventional-changelog team can consider building out a tool that can upload the results of npm pack to an existing GitHub release page.