Use README from master when updating Docker Hub description
#918
Conversation
As discussed in #915 (comment), when a tag is pushed, we update the Docker Hub description based on the `README`... in that tag. Which means when a patch for an older version is released, we effectively roll back the description to an older version. Changes: - on tag `push`, update the Docker Hub description in a seperate job based on `master` - bonus - because it was in a matrix we _were_ doing it multiple times - when the `README` or associated architecture is updated, rebuild as well
| on: | ||
| push: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
Not sure we should do this until changes have been back ported to avoid mismatch? (which will get trigger via .github/workflows/tag_image_push.yml). I think this is how it should work?
- Docker is release tagged: this will run from via
.github/workflows/tag_image_push.ymland branch will bemaster - If someone wants to publish manually, they run
.github/workflows/update_readme.ymland they can select the branch but defaults tomaster
There was a problem hiding this comment.
Not sure we should do this until changes have been back ported to avoid mismatch? (which will get trigger via
.github/workflows/tag_image_push.yml). I think this is how it should work?
- Docker is release tagged: this will run from via
.github/workflows/tag_image_push.ymland branch will bemaster- If someone wants to publish manually, they run
.github/workflows/update_readme.ymland they can select the branch but defaults tomaster
Sorry I don't understand, especially with my recent changes. Could you have another look, please?
There was a problem hiding this comment.
So this will trigger after PR is merged to master?
If yes then we shouldn't do it I think because of "Not sure we should do this until changes have been back ported to avoid mismatch"
We never release master so doesn't make sense. We should only update description 1) release tag 2) manually and both should come from master
That said doesn't look like the OS/EE description is version specific. But lets say we add something new then description should not be updated unless that is released. But as a rule of thumb, we should not add anything in README that is version specific as that would be confusing. Or mention version if the info is specific to a HZ version, where necessary
Does that make sense?
There was a problem hiding this comment.
So this will trigger after PR is merged to
master?
Yes
That said doesn't look like the OS/EE description is version specific. But lets say we add something new then description should not be updated unless that is released. But as a rule of thumb, we should not add anything in README that is version specific as that would be confusing. Or mention version if the info is specific to a HZ version, where necessary
Remember that there's only one README for all versions - e.g. we even talk about config changes required for HZ 3.x in the README. So if we add a new thing that necessitates a README change, it'd already need to be backwards compatible.
then we shouldn't do it I think because of "Not sure we should do this until changes have been back ported to avoid mismatch"
We never release
masterso doesn't make sense. We should only update description 1) release tag 2) manually and both should come from master
{...}
Does that make sense?
Not really!
There was a problem hiding this comment.
Remember that there's only one README for all versions - e.g. we even talk about config changes required for HZ 3.x in the README. So if we add a new thing that necessitates a README change, it'd already need to be backwards compatible.
Lets say we change something that needs README change. Lets say this change is appreciable and only for 5.5.6.
So I would make the code changes + README (mention 5.5.6) + PR + merge to master + backport to 5.5.z
At this point the change is not in any release as we are yet to do 5.5.6. So the description should be updated only when we release 5.5.6 (which will happen automatically)
Makes sense? If not then let me know and I will approve. This is not a biggy. We should just be mindful when updating README as its now coming always from master
Makes sense?
If not then I need to go back to school :)
There was a problem hiding this comment.
Lets say we change something that needs
READMEchange. Lets say this change is appreciable and only for 5.5.6. So I would make the code changes + README (mention 5.5.6) + PR + merge tomaster+ backport to 5.5.z At this point the change is not in any release as we are yet to do5.5.6. So the description should be updated only when we release 5.5.6 (which will happen automatically)
Ok - I understand. But if we release an update early, I don't see that as a big problem as we have to maintain backwards compatibility anyway.
There was a problem hiding this comment.
Yes true but I am thinking if user sees 5.5.6 then will start looking for the release and won't find it anywhere. Would look unprof IMO. We could say like 5.5.6 (to be released) but thats a hassle. Granted this would be rare but just incase
So if we need to update description (like we have to fix the anchors), then that should be a deliberate action (either you would run after PR merge or from dev branch to test things). Otherwise, we always update description during a release; same as code changes. Publishing from master should always be deliberate. This makes things simpler!
There was a problem hiding this comment.
I understand but don’t think it’s a massive issue. If it’s a dealbreaker for you we can change it otherwise I think leave as is.
JackPGreen
force-pushed
the
use-`master`-as-documentation-source
branch
from
026b72a to
ac270b3
Compare
JackPGreen
force-pushed
the
use-`master`-as-documentation-source
branch
3 times, most recently
from
4756b56 to
c36ff43
Compare
JackPGreen
force-pushed
the
use-`master`-as-documentation-source
branch
from
c36ff43 to
e0e165c
Compare
| on: | ||
| push: | ||
| branches: | ||
| - master |
There was a problem hiding this comment.
So this will trigger after PR is merged to master?
If yes then we shouldn't do it I think because of "Not sure we should do this until changes have been back ported to avoid mismatch"
We never release master so doesn't make sense. We should only update description 1) release tag 2) manually and both should come from master
That said doesn't look like the OS/EE description is version specific. But lets say we add something new then description should not be updated unless that is released. But as a rule of thumb, we should not add anything in README that is version specific as that would be confusing. Or mention version if the info is specific to a HZ version, where necessary
Does that make sense?
As discussed in #915 (comment), when a tag is pushed, we update the Docker Hub description based on the
README... in that tag. Which means when a patch for an older version is released, we effectively roll back the description to an older version.Changes:
push, update the Docker Hub description in a separate job based onmasterREADMEor associated architecture is updated, rebuild as wellREADMEupdates fromtag_image_pushto the new action, which simplifies a lotTested here.