CI/CD usage scenarios

[shudac]

Hello,

Trying to set a CI/CD scenario based on GitHub Flow or GitLab Flow with aim to have full automation, even in semantic versioning and releases including auto update with channels. E.g: https://levelup.gitconnected.com/semantic-versioning-and-release-automation-on-gitlab-9ba16af0c21

According to my research and tests it seems that the intended versioning and auto update scenario is entirely tied to version attribute of package.json. Which needs to be (manually) altered to achieve desired and correct functionality of build and auto updates.

While electron-builder.env can be automatically generated as part of CI/CD pipelines, and used to populate values in electron-builder.yml, the version of an app itself (and whole auto update logic) is still depended on version attribute from package.json.

Documentation mentions an attribute currentVersion, however it is unclear to me where and how can it be set in context of electron-builder.yml and electron-builder.env

What is the way to switch from using hardcoded values in package.json and use electron-builder.env dynamically created during CI/CD pipelines to still have correct versioning auto updates and channels functionality?

Thank you

Stefan Hudac

• Electron-Builder Version: 24.9.1

• Node Version: 21.6.1

• Electron Version:
• Electron Type (current, beta, nightly):

• Target: AppImage

[mmaietta]

I think you can override the package.json version via metadata attribute in the electron-builder config and passing version in there

[shudac]

Thanks.

Yes, however the variables in pattern (in metadata section) were not substituted. Seems in metadata must be an attribute set to a proper string value, not template.

But I found solution. I am using JS instead of YAML config file. This information and practice is not very obvious from docs.

Also not clear why values in metadata section cannot be provided as template strings and substituted as in other parts of the YAML...

[mmaietta]

It isn't clear? It's documented here: https://www.electron.build/api/programmatic-usage With the API specifications here: https://www.electron.build/api/electron-builder

[shudac]

I went through documentation again as you suggested and I confirm that it was and is not clear/obvious to me. Should you not point it out here, I would not consider the example related to configuration. I went with approach where my configuration JS file does not import any module and just plainly exports single configuration object copied from my YAML configuration. Substitution works and I am happy.

I would expect specific section under configuration dedicated to JS configuration option. I find electron-builder documentation not an easy to use and follow in general. Many times (and it relates to many projects) the documentation seems to be an afterthought and/or follows specific pattern of thinking of the documentation creator which may not be obvious to others.

However the electron-builder is a great and particularly useful project and I am very thankful for it and all the work and effort put into it. It allows me now to build our project automatically using gitlab-ci pipelines, using channels electron-builder/electron-updater provides. I am able to use a branching strategy close to desired. The remaining task is to find out solution which would suit working on feature branches as the numbering pattern of features does not follow semVer pattern and therefore does not work well with auto updater feature...

Again thank you for very valued answer.

[mmaietta]

That's very great feedback. I agree that the documentation is not particularly the best format, it was the results of the project owner. Would love to hear more if you're willing on where or what format would be preferred. The docs generator is fairly complex and I've tried other formats before but with little success in translating the tutorial docs over in a usable manner

Re: feature branches, I'm actually not familiar with the use case there. Would you mind elaborating? It could be that semver parsing could be overkill in electron-builder.

[shudac]

There are some standardised workflows of git repo management available. Namely Git Flow, GitHub Flow or GitLab Flow... I want my team to adopt a flow where we can work in organised way not stepping on each other toes while working on our SuperApp.

Basic flow is that everybody commits to the main branch of SuperApp repo. Everybody is able to build and test locally. Once we get passed local tests a branch alpha-1.0.0 is created. This triggers CI/CD to build and deploy version SuperApp-1.0.0-alpha available for team to test. The development still continues on main branch and with further progress on app development the main branch is merged into branch alpha-1.0.0. Which triggers builds and app is available for the team to test.

This comes eith an issue as electron-updater will not function as the SuperApp is still v 1.0.0 on channel alpha. The workaround is to create new alpha branch with semVer third number increased to have auto update working correctly while developing and testing and team understands that in used name convention for branches (alpha, beta, rc, ...) the third number does not mean fix, but progression to ensure auto updates working. With production release the branch release-1.0.0 is created and CI/CD is designed to remove channel portion from version generating SuperApp-1.0.0

Once the SuperApp is out there for ppl to use, another flows may get introduced. Once bug is discovered, existing branch release-1.0.0 is branched out into hotfix-1.0.0. This triggers CI/CD to build and deploy SuperApp-1.0.0-hotfix for team to work and test on. The issue over here is that while pushing into repo on this branch (hotfix-1.0.0) the artefacts are generated, but as the version stays the same electron-updater will not get triggered to auto update to the new version on this channel. So members of the team must download new version manually and in process of working on a hotfix a bug may get introduced into auto update which may not get caught and may propagate into further development.

Once the hotfix bug is fixed and tested, new production branch is created release-1.0.1. CI/CD generates and deploys new build, and electron-updater will catch new version for production channel (should the auto update not get affected during bug fixing as I mentioned higher)... The hotfix-1.0.0 branch is then merged into main branch to preserve the bug fix for future versions. The purpose of hotfix-1.0.0 is then fulfilled and later the branch can be removed.

Important here is to maintain strict branch naming convention between release and hotfix branches, opening single hotfix branch for particular release version, resulting into new release branch with increased third semVer number. Release branches should be always created as new, never to merge into!

Also, I understand that there are practices encouraging doing hotfix branch from main branch (which might moved meanwhile significantly from the time the original release-1.0.0 was created). Hotfix branch is being worked on, committed into, then merged back to the main branch and then cherrypicked into new release branch. But from my experience cherrypicking into release branch from main branch (which usually evolved significantly) almost always introduces more challenges than gains. But that's just my experience...

So this would cover most of app lifecycle and CI/CD challenges of an average SuperApp. However in practice there is often necessity to work on functionality which is experimental, not always thought through or new approaches are tested. The point is not to pollute main branch with such a code. For that usually feature branch is created and only merged into main branch once the feature was confirmed as viable. Some teams, using agile scrum, do create a feature branch for every story they work on. And for that I have no suitable CI/CD flow in relation to semVer pattern electron-updater relies on...

So to explain from point of view of devOps - git and CI/CD: the electron-updater channels and the branch names are closely related in my implementation, and semVer pattern logic does make things challenging. The solution I described is the best I was able to come up with so far, based on my experience and research. I am not saying it is the best overall or the only possible and I'd appreciate to have further discussion on implementing more versatile and/or advanced CI/CD pipelines, beyond the single branch ones I was able to find and research so far...

Also I want to clearly state that the way electron-updater works is not bad, quite an opposite. The design does make sure, that not "production ready" version is ever released to the world. So I am not sure if we can have the best of both worlds, auto update on any channel not being limited by semVer, and at the same time having a security of not releasing not ready app, guarded by the semVer, having it all controlled by CI/CD...

Thank you for having an opportunity to explain myself. I hope I was clear enough and someone/anyone could benefit from it.