jdeploy github actions questions (setting app version, release notes)

[jpage4500]

Hi,

If you didn't see my other question -- I'm very new to jdeploy and already a huge fan!

I tried to get the jdeploy github actions script working and I think I did but have 2 questions about it.

1. how do I set the release version? If someone looks at the releases page they see "Native Bundles (master)" and "jDeploy Package Info" which don't have any version info in them.

2. I'd like to add some release notes to each github release. Is that possible?

For example, if I look at https://github.com/shannah/swingset2/releases I can't tell what the latest version is. I'd rather just have a single release that looks closer to this one https://github.com/shannah/swingset2/releases/tag/1.0.11-alpha.7

Maybe the answer isn't to use the jdeploy GA plugin but to use some other generic plugin like this one. Would that affect auto-updating or anything else? Sorry, I'm still not sure the difference between the npm and github releases just yet (ie: is that "jDeploy Package Info" tag used by jdeploy somehow?)

---

For more context here's what I'm trying to do:

• work on a feature in a branch.. create a PR and merge it into develop branch
• have app built and released

I've got most of this logic done with github actions today. The app is built and I'm able to fetch the app version into an env variable. I then modify the package.json file to match the version just built (I don't want to update versions manually!). Finally, I run the jdeploy github action.

[shannah]

Hi Joe,

For numbered releases, you should create a new release in github. The jDeploy action will automatically append the native installers to this release's artifacts, and add download links in the release notes.

If you want to add additional release notes, you should be able to edit the release and add your own notes as desired.

Does this answer your question?

[jpage4500]

thanks @shannah - yes if you have an example I'd appreciate it!

My goal was to avoid having to manually create a new release but instead to automatically create a release for every PR+merge into the develop branch. Is that possible?

[shannah]

For "branch" releases (i.e. not tagged), the version number is always "0.0.0-". In these cases the version number isn't relevant since the release is always "synced" to the latest commit on the branch.

So it sounds like, when you are merging into your "develop" branch, you intend this to get tagged as a release automatically. This is possible via github actions, and a common approach is to use semantic versioning.

There is a github action for this here: https://github.com/marketplace/actions/git-semantic-version

The gist is that you provide "hints" that follow a well-defined convention in your commit subjects, and the plugin will automatically create a release on each commit.

If you set up this action to generate your releases, then you would set up your jdeploy action to run on "tag".

So the flow would be:

1. Merge to develop
   -> Semantic version github action runs on merge
   -> jDeploy action runs on tag.

Since you're using Github actions anyways, I suggest using Github releases for your deployment instead of npm - but npm is fine too.

Here is a typical workflow that I use for jDeploy. It includes some extra fancy stuff, such as generating DMG installers on Mac using your own Apple developer certificate, but it can be used as a template.

https://github.com/shannah/jdeploy-cn1test-3/blob/master/.github/workflows/jdeploy.yml

If I were you I would attack this problem one piece at a time. First get semantic releases working. Then set up jDeploy to publish your native bundles for the tags that semantic releases creates.

[shannah]

Actually, remembered it wrong. I was thinking of "conventional commits". Not semantic versioning. Conventional commits uses semantic versioning, but it defines commit conventions that would trigger the semantic versions.

https://www.conventionalcommits.org/en/v1.0.0/

Here is a github action that supports conventional commits.
https://github.com/webiny/action-conventional-commits

We use conventional commits on some repos, and it works well.

[shannah]

@jpage4500 Thanks for raising this use case. I think this presents an interesting and useful case, so I'm going to put together an example and documentation using conventional commits combined with jdeploy to generate releases in this way. Targeting next weekend for this.

[jpage4500]

thanks! yeah I'm probably not using a typical release strategy.. I'm just using a single branch (develop) as my release branch.

The thing that was confusing me with the jdeploy github action was the version that was displayed in the homepage (develop) and the version listed in the artifacts (android-device-manager-0.0.0-develop.tgz.

My app already has a version that's updated in the build itself (pom.xml). I was just looking for that version to be reflected when looking at either the github releases page or the jdeploy homepage.

[jpage4500]

@shannah - another GA plugin question..

I ran into an issue and while I don't think it's related to the plugin it's more of a side-effect from what I can tell.

The GA plugin creates a tag with the same name as the branch (develop). After this I noticed Sourcetree was giving me errors whenever I tried to create a new branch off of develop.

I included screenshots to show what I'm talking about.. again, I don't think it's a jdeploy problem but a Sourcetree problem.. something must be getting confused having a tag and a branch with the same name. But, the only way I can figure out how to get around it is to delete the develop tag

[shannah]

Thanks. looks like having tag with same name as branch is causing problems for it.
perhaps i should modify the naming convention for the tags and/or make it configurable.