dteviot
Create new github release with each pull
In github actions is already a workflow that automatically builds the addon. The idea is that this build is automatically released as a new version on github so that people can get the latest version on github. It looks like there is a pre-release flag that could be associated with such releases.
@dteviot doesn't have to upload the latest release to google drive anymore.
Related to #41 how should the versoning be handeled? 0.0.0.160-beta.01 and 01 increases with each pull?
Another option would be to override the latest pre release binarys with the new ones. 0.0.0.160-beta Problem: If someone installs this version it could be unclear to him that a few weeks later the version with the same name is another version.
I don't know how github actions work so help is appreciated.
Hmm, this is something that both Azure and Jenkins provide in their workflows, but I'm not entirely sure on the implementation for GitHub. A lot would be based on implementing it into the existing workflow: https://github.com/dteviot/WebToEpub/blob/ExperimentalTabMode/.github/workflows/node.js.yml
An existing Workflow which seems to do this is here: https://github.com/github/safe-settings/blob/main-enterprise/.github/workflows/create-pre-release.yml
Some documentation & general information https://blog.kubesimplify.com/automated-github-releases-with-github-actions-and-conventional-commits https://github.com/marketplace/actions/github-releases-for-automated-package-publishing
I haven't read it all yet myself, but it should make for some interesting reading...
Random note from another dev issue, don't want to spam that thread:
@Kiradien why can't you run lint locally?
I've fixed the issue locally a few times, but it always ends up being a pain when running my Windows install.
Both - Linux for work, Windows for relaxation. However, I tend to be booted into Windows when I work on and test WebToEpub.
If you use vscode in the right bottom corner is a button where you can change lf to crlf.
I did that once before; ended up needing to change every single parser to CRLF before it got rid of the error, which I had to revert to check in. I'd honestly be more worried about it if it wasn't just me hitting this, 90% sure there's an installation error on my end since no one else hits these.
If I really need to compile, I may as well just delete the linebreak-style req from eslintrc all together, resulting in a single file change instead of dozens.
This looks like a solution to me. https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux.
As regards versioning, I think it should go something like 1.0.x.y where x gets bumped each time a version is published to the Chrome and Firefox stores, and y is bumped with each commit. Resetting to 0 when x is bumped. But you really want an automated process to handle that, as part of the commit to GitHub.
I created it and the latest build will always will be here: https://github.com/dteviot/WebToEpub/releases/tag/developer-build
@gamebeaker It's not doing the latest build. If you examine the source from https://github.com/dteviot/WebToEpub/releases/tag/developer-build, the version in the manifest file is 0.0.0.161. And I don't see the parser I just added. (novelsect) The Full Changelog also shows the history is incomplete. Also, the instructions don't mention that the extensions are in the zip file, so you'll need to download the zip, then extract the wanted extension from it.
@dteviot did you download it? If i download the zip and look at the Chrome zip i see your new NovelsectParser.js file and the manifest version is 0.0.0.163
The 5 commits to ExperimentalTabMode message is wrong. (edit: found fix)
The Full Changelog also shows the history is incomplete.
I would say it is wrong because the latest version was 160 not 159 but i see see all changes.
Also, the instructions don't mention....
You are right. On your google drive the firefox version is a zip file instead of xpi is it just renamed or is it something else? Are your realeses on github signed?
Maybe you were to fast and the action wasn't completed yet.
@gamebeaker
You are right. On your google drive the firefox version is a zip file instead of xpi is it just renamed or is it something else?
Yes, I renamed it. I think because long ago the instructions said to unzip it and people get confused being asked to unzip an xpi.
However, Firefox doesn't require unzipping to load an "in-development" extension.
Also, did renaming, so Firefox and Chrome versions were labelled.
I probably need to have a think about this.
You can trigger a new release manually here: https://github.com/dteviot/WebToEpub/actions/workflows/AutoRelease.yml
I gave the different numbers in the version names:
0.0.0.160
milestone.majore.minore.dev
If for example minore is choosen it increases+1 and dev gets set to 0 and if milestone is choosen it gets +1 and all other gets set to 0. If the value is not valid it is treated as dev.
@dteviot already uploaded the new release to firefox and chrome? I ask because i thougt the next version will be something like: 0.0.1.0 or 1.0.0.0 not 0.0.0.167
@gamebeaker Yes, I uploaded the build. And you're right, I should have labelled it 1.0.0
@dteviot Ok if for the next release just execute the workflow with the parameter "milestone"
https://github.com/dteviot/WebToEpub/actions/workflows/AutoRelease.yml
than the version will be 1.0.0.0
Why increase Version number with github actions and not simple with a push?
After each push the dev number get increased automatically wich means the new Version would be X.X.X.1