-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
merge buildman scripts, automate deploy and release #130
Conversation
if deployment succeeds, the build workflow will create a github release, along with a matching a git tag. the placeholder release description should be updated, and the attached installers.zip replaced with separate installer packages contained within itself. the workflow has to attach all artifacts as a single zip because the relevant action cannot upload multiple files to a release yet (not without insane workflow step duplication.)
(connectivity note removed because it should be obvious)
I have added the secret environment keys. |
Edited: |
well, I don't think it matters that earlier version exist in the repo, because after any public announcement, users will get the latest version, 2.0.0, from the repo by default. they don't even need to notice the past releases exist there. that said, those 1.5.x uploads were generated mainly to make sure this mechanism works (those are authentic builds from the source code though). i'm not opposed to removing them if necessary. |
@bdeshi I am sorry for not to raise my issue clearly. I was talking about the ReadMe file changes. I have updated the comment, can you check it again, please? |
Oh ok. I understand. I'll revert the readmes for the time being. |
@bdeshi Can you open another PR with ReadMe changes? We can merge it when we release the next version! |
+ updated build candidates + ubuntu package upload optimized + publish.sh sanitized a bit
the deploy workflow's distro list needs to be updated periodiclly. particularly, the ubuntu versions list must be kept up-to-date with their current latest short term and long term versions. otherwise it will break deploy workflow, because canonical moves repos into archives fairly often. if our deploy workflow tries to build for a ubuntu version that has been archived, it will fail. for example, as of this commit, ubuntu19.04 repo has already been archived, so I had to use 19.10 in the build list instead.
(thanks @mominul) Co-Authored-By: Muhammad Mominul Huque <mominul2082@gmail.com>
the version number in or it could be removed altogether. that's one of the reason why all this repo set up was done basically. 😅 |
@ahmubashshir: the database files do exist in the repo. |
@bdeshi please set |
Thanks @ahmubashshir. fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! 🎉
major changes
so users may add openbangla's repo to their package manager and install with normal commands like
apt-get install openbangla-keyboard
version.txt
in project root. supplies version info to cmake and ci scripts.minor changes
added distro/repo-wise install instructions.(reverted and split into separate pr)release process
notes
configuration
threefour secret keys for bintray apikey, username, org gpg id, gpg key.packages are built for ubuntu LTS versions only. LTS packages may be installed on interim versions without problems. (see this issue: bdeshi/openbangla-keyboard#2)tools/install.sh
has to be updated after final release.