Document / facilitate the migration from https://hub.docker.com/r/sailfrog/cypht-docker to https://hub.docker.com/u/cypht

[marclaporte]

https://github.com/cypht-org/cypht-docker/ was the official Docker image builder of Cypht. It is being replaced:

• Docker-related code will be part of the main Cypht repository so https://github.com/cypht-org/cypht-docker/ will be deprecated.
• https://hub.docker.com/u/cypht will replace https://hub.docker.com/r/sailfrog/cypht-docker as per Decide where Cypht's Docker images will live #1016
• Here is background info: The good, the bad and the ugly: We need a Docker expert to guide us! cypht-docker#31

This issue is to track what should be done to facilitate this transition once https://hub.docker.com/u/cypht is working well enough.

As of 2024-05-25, https://hub.docker.com/r/sailfrog/cypht-docker/ is serving up 5 month old code from Cypht master, which is missing a lot of fixes and enhancements compared to Cypht 2.0.x or today's master.

[marclaporte]

Until https://hub.docker.com/u/cypht is operational, https://hub.docker.com/r/jonocodes/cypht can be used to test #1001

[jonocodes]

We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.

Once the new image is up in https://hub.docker.com/u/cypht we should update the readme on https://hub.docker.com/r/sailfrog/cypht-docker to point people to the new cypht/cypht image.

[jonocodes]

Also since I have creds now I can publish something right away to cypht/cypht. I'm just not sure what to tag to use. Maybe it will just be a timestamp or something cryptic so its not yet used. Or perhaps I'll just use 'latest' for now.

[jonocodes]

Also also we should probably merge this first: #1001
Preferably someone will 'accept' it before I merge.

[marclaporte]

Also since I have creds now I can publish something right away to cypht/cypht.

Yes, please just go for cypht/cypht

[marclaporte]

Preferably someone will 'accept' it before I merge.

Done and merged.

We used to only have master, fewer developers, and all MRs reviewed by Jason Munro (project founder), so master was kept very stable.

But now

• Jason is on a break.
• the community is bigger, more projects are underway.
• mistakes will be made: several junior devs who will make mistakes + senior devs who will work on more complex things, which will also lead to issues.

So I decided we would have stable branches: https://github.com/cypht-org/cypht/wiki/Lifecycle

Thus, it's OK to have some short term mess in master while we figure out things like this.

[marclaporte]

I'm just not sure what to tag to use. Maybe it will just be a timestamp or something cryptic so its not yet used. Or perhaps I'll just use 'latest' for now.

I don't know enough on how this works to provide guidance.

We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.

Agreed. Just put a readme pointing to new location.

[marclaporte]

I'm just not sure what to tag to use. Maybe it will just be a timestamp or something cryptic so its not yet used. Or perhaps I'll just use 'latest' for now.

So 'latest' would be Cypht master? Why not call it master?

[marclaporte]

Oh wow!

• https://vsupalov.com/docker-latest-tag/
• https://medium.com/@mccode/the-misunderstood-docker-tag-latest-af3babfd6375
• https://www.howtogeek.com/devops/understanding-dockers-latest-tag/

[jonocodes]

Oh wow!

* [vsupalov.com/docker-latest-tag](https://vsupalov.com/docker-latest-tag/)

Ha yes. I was about to post the same article.
Long story short is 'latest' is not well defined and not well understood. Makes more sense for development then distribution - though some projects have started taking it upon them selves to keep it meaningful in their project specifically.

I would say the same problem is for 'master'. When in 'master' was it made? Today? Last month?

There was talk of a 'nightly' tag, which I think may be more meaningful - that is if it is really nightly.

I personally try to avoid these altogether when distributing images. And stick to version numbers. That way you know what you are getting.

[jonocodes]

All that being said I have posted to 'latest' while we figure that out:
https://hub.docker.com/r/cypht/cypht

We can delete that tag if we want, but it will be more clear when a release happens.
By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.

[marclaporte]

By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.

Sure! @josaphatim can release 2.0.2 Does he need to do anything different than 2.0.1?

[marclaporte]

have posted to 'latest' while we figure that out

+1

[jonocodes]

By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.

Sure! @josaphatim can release 2.0.2 Does he need to do anything different than 2.0.1?

I hate to nit-pick. But this would be a feature release not a bug fix. So to stick inline with symantic versioning it would be 2.1.0.
But I guess that would mess with the support schedule?

[marclaporte]

But I guess that would mess with the support schedule?

No, it wouldn't. 2.1.x will just replace 2.0.x as the supported stable branch.

[marclaporte]

I hate to nit-pick. But this would be a feature release not a bug fix. So to stick inline with semantic versioning it would be 2.1.0.

This is a good topic. We set general guidelines, but it's only when it hits reality that we can refine our processes. Thank you. I didn't see this as a new feature because nothing changes for the user. But for a sysadmin, it is significant and they should review the changelog. I am fine to tag it 2.1.0 (And say 2.0.x is EoL)

On a related note, master will soon diverge in a material way from 2.x, by requiring PHP 8.1+:
#1044. So the Docker files will need to diverge as well.

[marclaporte]

@jonocodes should #1044 be held back?

@josaphatim please release Cypht 2.1.0

[rodriguezny]

We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.

Once the new image is up in https://hub.docker.com/u/cypht we should update the readme on https://hub.docker.com/r/sailfrog/cypht-docker to point people to the new cypht/cypht image.

Yes, we should take it down but I think not now. For the moment we can just update the readme adding a deprecated message and a link to https://hub.docker.com/u/cypht so people will know where the new image lives. And after a while we can take down the sailfrog image.

[rodriguezny]

All that being said I have posted to 'latest' while we figure that out: https://hub.docker.com/r/cypht/cypht

We can delete that tag if we want, but it will be more clear when a release happens. By the way, this maybe would be a good time to do a release? Then we can get a real version number in there.

Thanks for the new image posted, we can now update sailfrog image readme to point to https://hub.docker.com/u/cypht.

[jonocodes]

@jonocodes should #1044 be held back?

I think it can get merged. Then the first real docker release would be php 8. The docker work will not be hard. Side note: I'm away from computer for a few days.

But you do need to consider the cypht version. Maybe 2.1.0 is fine for a php upgrade since it does not seem to be a breaking change at this point.

[jonocodes]

I hate to nit-pick. But this would be a feature release not a bug fix. So to stick inline with semantic versioning it would be 2.1.0.

This is a good topic. We set general guidelines, but it's only when it hits reality that we can refine our processes. Thank you. I didn't see this as a new feature because nothing changes for the user. But for an sysadmin, it is significant and they should review the changelog. I am fine to tag it 2.1.0 (And say 2.0.x is EoL)

It can be a little unintuitive but when I work on projects I favor revving the middle number the most. Thats the default. On another project I'm working on It's not uncommon that the minor version will update several times a day (ie 2.3.4 to 2.4.0 to 2.5.0).

I reserve the last digit to mean this release only fixes a bug and we don't think it would lead to a regression. It's more of an emergency valve that should not happen often.

[marclaporte]

Maybe 2.1.0 is fine for a php upgrade since it does not seem to be a breaking change at this point.

Ok, let's do that. And it will make it easier to backport things from Cypht master to 2.x (which I expect we will do a lot of). I updated: https://github.com/cypht-org/cypht/wiki/Lifecycle

Users who are stuck on PHP 7.4 (or even all the way back to PHP 5.6) can use Cypht 1.4.x which is LTS.

Here is task: #1050

[marclaporte]

I reserve the last digit to mean this release only fixes a bug and we don't think it would lead to a regression. It's more of an emergency valve that should not happen often.

That was pretty much my original idea for the general lifecycle except I didn't even plan for the last digit. So I had in mind 2.0, 2.1, 2.2, etc. but 2.0.0, 2.1.0, 2.2.0, etc. is better with the emergency valve as you call it :-)

So we'll very likely get to 2.10.0 before we release 3.0, which is fine!

[marclaporte]

Also to do: update instructions on https://www.cypht.org/install-2x.html

[rodriguezny]

We should probably take down the sailfrog image eventually but I dont think it has to happen for a while.

Once the new image is up in https://hub.docker.com/u/cypht we should update the readme on https://hub.docker.com/r/sailfrog/cypht-docker to point people to the new cypht/cypht image.

@marclaporte I updated https://hub.docker.com/r/sailfrog/cypht-docker overview. I think we/you should also announce the migration of cypht docker image to the new account on https://app.gitter.im/#/room/#cypht-org_community:gitter.im.

[jonocodes]

OK. Perhaps wait to announce until we have a proper tag in the new repo.

[marclaporte]

OK. Perhaps wait to announce until we have a proper tag in the new repo.

ok, I pointed people here so they get latest status

[rodriguezny]

Also to do: update instructions on https://www.cypht.org/install-2x.html

Also to do: update instructions on https://www.cypht.org/install-2x.html

cypht-org/cypht-website#60

[jonocodes]

Ok, I have created a tag cypht/cypht:2.0.1
where I backfilled the docker work on top of the 2.0.1 git tag. Then I removed 'latest' from dockerhub for now. For reference you can see the work here:
https://github.com/jonocodes/cypht/tree/2.0.1-docker

Lets call this the first official tag and go ahead and update docs/announce. Next I need to figure out how to build for ARM.

[jonocodes]

This updates old references:
#1053

Not sure what the PR review policy before merging is.

[marclaporte]

Not sure what the PR review policy before merging is.

In general, let someone else review and merge. But if you are confident it's low risk, you can merge it yourself.

[marclaporte]

@rodriguezny Can we have a nice logo on https://hub.docker.com/r/cypht/cypht ?

[rodriguezny]

@rodriguezny Can we have a nice logo on https://hub.docker.com/r/cypht/cypht ?

Yes, we can. Let me update it.

[rodriguezny]

@rodriguezny Can we have a nice logo on https://hub.docker.com/r/cypht/cypht ?

@rodriguezny Can we have a nice logo on https://hub.docker.com/r/cypht/cypht ?

Done!

[marclaporte]

@jonocodes: Can we please have a new tag for https://github.com/cypht-org/cypht/releases/tag/v2.1.0? (now requires PHP 8.1)

Thanks!

[marclaporte]

@rodriguezny We have 944 stars on https://github.com/cypht-org/cypht but only 2 on https://hub.docker.com/r/cypht/cypht

Any ideas?

[rodriguezny]

@rodriguezny We have 944 stars on https://github.com/cypht-org/cypht but only 2 on https://hub.docker.com/r/cypht/cypht

Any ideas?

I think the fact is that not every github user or every community member has a dockerhub account. In the 2 stars, there is one of mine and the other one should be for @jonocodes or you or any one else. Let's remember community members to give us a star.

[marclaporte]

Oh! I thought it grabbed the stars from GitHub :-)

[jonocodes]

@jonocodes: Can we please have a new tag for v2.1.0 (release)? (now requires PHP 8.1)

Thanks!

Yes, 2.1.0 is now in docker hub.

Also I just added instructions so others know how to do the release:
https://github.com/cypht-org/cypht/wiki/How-to-release-Cypht#manually-releasing-a-docker-image

Side note: I think it would be nice to surface the version number either in the UI or in the HTML source to help with debugging user issues.

[marclaporte]

would be nice to surface the version number either in the UI or in the HTML

Done: #594

[jonocodes]

would be nice to surface the version number either in the UI or in the HTML

Done: #594

I think whats here is a good starting point. But it is focused on development.
a) I dont know how to enable it or where to find it displayed
b) I dont think it will display the tag version. only the checksum
c) I dont think it will work in docker since there is no git there

Ideally this would be shown to all users in production as a version number like 2.1.0

[marclaporte]

Ideally this would be shown to all users in production as a version number like 2.1.0

Agreed. Can you please add?

[marclaporte]

Yes, 2.1.0 is now in docker hub.

@jonocodes The front page of https://hub.docker.com/r/cypht/cypht still mentions PHP 7. Maybe best to remove version number since it can vary?

[jonocodes]

Ideally this would be shown to all users in production as a version number like 2.1.0

Agreed. Can you please add?

Lets make a ticket. It will take some work to sort out because we are going to have to write the version number to a file somewhere probably.

[jonocodes]

Yes, 2.1.0 is now in docker hub.

@jonocodes The front page of hub.docker.com/r/cypht/cypht still mentions PHP 7. Maybe best to remove version number since it can vary?

Updated. And now there are instructions in the wiki
https://github.com/cypht-org/cypht/wiki/How-to-release-Cypht#updating-readme-in-dockerhub

[marclaporte]

@rodriguezny what is left to do here, if anything?

[rodriguezny]

@rodriguezny what is left to do here, if anything?

AFAIK, nothing is left. Unless @jonocodes says other thing.

[jonocodes]

Looks good to me. Thanks.