mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 04:56:03 +03:00
[GH-ISSUE #1175] Automate Docker builds (Especially from Master, but might as well do for all the releases) #595
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#595
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @marclaporte on GitHub (Aug 15, 2024).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/1175
Originally assigned to: @SKB-TECH on GitHub.
A sizable part of Cypht users install it via Docker. Thanks to @jonocodes via https://github.com/cypht-org/cypht-docker/issues/31, we now have: https://hub.docker.com/r/cypht/cypht
As of now, Docker releases (of Cypht stable releases) are manual. This is not a problem as we release stable versions every 2-3 months or so. However, for the development / testing / community process, it's causing quite a bit of friction. We need a way for community testers to get the latest Cypht from master. It could be a daily build, or even for each commit.
A nice side-effect is that will likely help us catch build bugs sooner.
Thoughts?
Thanks!
@jonocodes commented on GitHub (Aug 15, 2024):
Ok, thinking out loud here....
We can use the date as a tag, but there is no reason to pollute dockerhub with tons of images. So yes, I do think the 'daily' version could be good here.
I think we should tag it 'nightly'. Not sure why, but I think that is a more commonly used/understood name? See https://www.mozilla.org/en-US/firefox/131.0a1/releasenotes/
So lets create a github workflow that does that every day. I think @wangxiaoerYah maybe can do this since he knows about github workflows. You can follow this for the tagging process: https://github.com/cypht-org/cypht/wiki/How-to-release-Cypht#manually-releasing-a-docker-image
To clarify every day an image will be built and pushed with the name 'cypht/cypht:nightly'. Thus overriding the previous day's build.
Separate items not discussed in this ticket:
@marclaporte commented on GitHub (Aug 15, 2024):
I am OK with 'nightly' but 'daily' seems a bit better:
https://en.wikipedia.org/wiki/Daily_build
@marclaporte commented on GitHub (Aug 29, 2024):
https://github.com/cypht-org/cypht/releases/tag/v2.3.0 was released and now also on DockerHub: https://hub.docker.com/r/cypht/cypht/tags
@jonocodes commented on GitHub (Aug 29, 2024):
Great. Thanks @Shadow243
@neotwix commented on GitHub (Sep 11, 2024):
Hello,
Do you have plan to make a workflow for arm64 too ? sailfrog/cypht-docker contain one where the official not.
thnaks for your work.
@rodriguezny commented on GitHub (Sep 11, 2024):
Do you mean builds for arm architectures ? Yes, we will add them too.
@neotwix commented on GitHub (Sep 16, 2024):
Yes For the arm architecture. I should be Fine. Thanks
@rodriguezny commented on GitHub (Sep 16, 2024):
Ok, it will be added ASAP.
@marclaporte commented on GitHub (Sep 28, 2024):
Please add manual instructions ASAP to ease testing.
@rodriguezny commented on GitHub (Oct 1, 2024):
Hello, I added a build for arm64.
linux/arm64 added: https://hub.docker.com/r/cypht/cypht/tags
@rodriguezny commented on GitHub (Oct 1, 2024):
arm64 added https://hub.docker.com/r/cypht/cypht/tags, you can test it.
@marclaporte commented on GitHub (Oct 28, 2024):
Re-opening as we don't yet have Docker builds from master. It would really smooth out our dev-test feedback loop, like here: https://github.com/cypht-org/cypht/issues/1153#issuecomment-2440240071
Also, for releases, the Docker part is manual. This is low priority as it's a manual operation that only needs to be done for stable releases (every few months).
@jonocodes: I remember you had a mental roadmap. Can you share some more wisdom?
Thanks!
@marclaporte commented on GitHub (Oct 28, 2024):
ok, I found "After that we decide how to work this into a github action/automation for the next release perhaps. And how to maintain 'latest' and other non-versioned tags." here: https://github.com/cypht-org/cypht/pull/1001#issuecomment-2130022277
@marclaporte commented on GitHub (Oct 28, 2024):
I agree with the principle.
Reminder of our lifecycle: https://github.com/cypht-org/cypht/wiki/Lifecycle
Importantly, 2.x is supported for one year once 3.0 is released. Thinking of use cases, how about something like this?
So users must proactively determine a specific version, or latest stable release per branch, or daily build for master and major versions.
@marclaporte commented on GitHub (Oct 28, 2024):
So if tests fail, cypht/cypht:master-daily can be stuck to a few days ago. That is OK, as we'll fix it fast enough and it's less risky for users.
We already have automated tests for each merge requests before they are accepted in master. What would be different between daily build tests? Some longer tests?
@marclaporte commented on GitHub (Oct 28, 2024):
@wangxiaoerYah: @SKB-TECH will now start working on this, so now is a good time for any suggestions.
Thanks!
@jonocodes commented on GitHub (Oct 28, 2024):
Yes I think this sounds good. And I agree that having daily fall behind it tests break is the way to go.
I would go with this naming scheme as it seems more consistent with how others do it. However this is no real standard, so feel free not to.
My one concern is '2-daily'. The issue is that eventually it will no longer be updated, but will still be called 'daily'. But this is a minor concern and can probably be cleared up with documentation.
@marclaporte commented on GitHub (Oct 28, 2024):
@JohnXLivingston @mose @benoitg Any wisdom?
@JohnXLivingston commented on GitHub (Oct 28, 2024):
For what i understand, the main point of the daily build is to have some people test the most active branch.
This is not meant for developpers that are backporting fixes from 3.x to 2.x. Those will not use docker to test, but their dev environment.
If we have multiple daily version, i think nobody will use the old ones.
So, i think that only one daily build is enough, and I think it does not need to specify the major version in its name.
@JohnXLivingston commented on GitHub (Oct 28, 2024):
Something else that could be usefull: having special tags pointing to the latest stable version.
When you have a docker environment (for example using docker-compose), you must specify the tag you want.
Then, to update the software when there is a new release (for security fix for example), you have to do a
docker-compose pull.So, when users are using tag as "2.4.0", the image won't update if the new version has a different tag ("2.4.1", "2.5.0", ...).
Admins have to know there is a new version number, and have to change the configuration manually.
A common workaround is to have some special tags:
Those are just tags. Multiple tags can share the same build (no need to build X times, just build the new image, and change existing tags to point at it).
(i don't say that we must have all those tags, we just have to choose the preferred strategy)
@benoitg commented on GitHub (Oct 28, 2024):
My only concern it that we should make sure not to create a naming convention ambiguity with the snapshots we want to create for tiki, which are human triggered quasi releases meant for dogfooding in production, vs automated daily builds.
We didn't iron out a naming convention either, but tiki snapshots should have the branch and date as part of their name.
Yes it's not the same project, but since it's mostly the same people, there is a very real risk of confusion.
But i'm not well versed enough on the assumptions of the various tooling to form an opinion on the exact naming convention we should use.
@jonocodes commented on GitHub (Oct 28, 2024):
I do not like the use of 'latest' as it is ambiguous since it means different things to different docker systems/users. So I specifically avoid that term. In its place I think 'stable' may be appropriate. That being said, I dont encourage such use as a production user should at least know which major version they want to run. If 'stable' is pointing to 2, and there is a breaking change when it switches to 3, this will be problematic when the version gets changed out from under the user.
Agreed. That is the intent of the above daily/nightly above. I generally think this is a case that should not come up since the included build tools make it unnecessary, but thats just me.
Yes. Those are the intent of the above mentioned 'cypht/cypht:2' which is would point to 'cypht/cypht:2.4.0'
@marclaporte commented on GitHub (Nov 28, 2024):
This is needed to unblock this task: https://github.com/cypht-org/cypht/issues/1386#issuecomment-2506041009
@SKB-TECH commented on GitHub (Dec 4, 2024):
@marclaporte , @jonocodes , @rodriguezny , @benoitg , @JohnXLivingston , @neotwix
After having read all the comments, here is the synthesis even if we are already working on it:
If we've forgotten, please call us back.
@marclaporte commented on GitHub (Dec 28, 2024):
This would help for @knightsg to test master for: https://github.com/cypht-org/cypht/issues/671
@marclaporte commented on GitHub (Feb 4, 2025):
@SKB-TECH @rodriguezny @JohnXLivingston
https://hub.docker.com/r/cypht/cypht/tags seems good.
AFAICT, ARM64 is next (not a high priority)
https://github.com/cypht-org/cypht/pull/1325#issuecomment-2618567656
Anything else planned?
@rodriguezny commented on GitHub (Feb 4, 2025):
Apart from arm64 support, we have also to automate builds for releases.
@rodriguezny commented on GitHub (Jul 10, 2025):
Auto-build for releases has been added by https://github.com/cypht-org/cypht/pull/1543
@SKB-TECH commented on GitHub (Aug 11, 2025):
add multi-platform daily builds: https://github.com/cypht-org/cypht/pull/1608
@marclaporte commented on GitHub (Aug 21, 2025):
What is the next step?
@SKB-TECH commented on GitHub (Aug 21, 2025):
@rodriguezny can now connect all things to build images daily
@rodriguezny commented on GitHub (Aug 21, 2025):
I reviewd the images on dockerhub, we have now daily builds for arm64 architecture, good. But i noticed a new tag "buildcache", I left you a comment about on avantech.
@rodriguezny commented on GitHub (Aug 21, 2025):
We are almost done, we have automted daily build with amd64 and arm64 architectures and automated release build (build for each new tag) done in https://github.com/cypht-org/cypht/pull/1543 but haven't yet seen the last one in action because there is no new release has been made since the MR has been merged. Also I took a look on https://github.com/cypht-org/cypht/pull/1543 and noticed that it doesn't include the arm64 platform (easy to add, I can submit an MR before a new release), and when cypht is released, tags start by v like v2.4.2 while on dockerhub we name tag without v (e.g : 2.4.2), so something to be fixed. @ljcbaby can you tell us how was the docker tag named when you tested https://github.com/cypht-org/cypht/pull/1543 ?
So I think those 2 things will be the last step on this unless something else is proposed.
@ljcbaby commented on GitHub (Aug 22, 2025):
Get tagsstep, you can change it if necessary, now it read tag name.@rodriguezny commented on GitHub (Aug 25, 2025):
Ok, thanks, I'll adjust.