search

Samagra-Development / WarpSQL

WarpSQL
https://samagra-development.github.io/WarpSQL/
Apache License 2.0
16 stars 28 forks source link

Implement Version Policy #120

Closed PiyushRaj927 closed 8 months ago

PiyushRaj927 commented 9 months ago

Changes

  1. Pinned TimescaleDB version to 2.13.0.

  2. Introduced PRE_RELEASE:

    • Prevents pushing the latest tag for Docker images of pre-release versions.
    • PRE_RELEASE is determined based on the current tag at the HEAD of the git tree. For instance, if the tag at HEAD is 2.0-alpha, the latest-pg15 image tag won't be pushed to the image registry.

  3. Updated Docker tag format:

    • If a tag 2.0.0 is present at HEAD, the format is 2.0.0-pg15.
    • If no tag is present, it's set as dev-pg15.

  4. Changelog Management:

    • Added CHANGELOG.md to track major changes.

  5. Updated release workflow:

    • Now uses the TimescaleDB version specified in the makefile instead of the main branch when input ts_version is empty.

Test

Tested workflow on my fork: https://github.com/PiyushRaj927/WarpSQL/actions/runs/7450274263 Docker images at https://hub.docker.com/u/d3bug77.

PiyushRaj927 commented 8 months ago

Fixes #119

singhalkarun commented 8 months ago

Can you detail this more, add examples?

Instead of making it dev-pg15, how about we have something like last commit id because the image will get lost out on a new commit?

Also, can we create a doc which explains how the workflow works in detail so that a someone exploring repository for first time also have a clear understanding how images get built.

PiyushRaj927 commented 8 months ago
  • Automatically sets PRE_RELEASE based on the current tag at the HEADof the git tree.

Can you detail this more, add examples?

I have updated the description to be more clear and added an example

  • If no tag is present, it's set as dev-pg15.

Instead of making it dev-pg15, how about we have something like last commit id because the image will get lost out on a new commit?

sure, Makefile are updated to tag the images as per the format dev-<HEAD SHA>-pg<version>

  • Documentations on Workflows

Also, can we create a doc which explains how the workflow works in detail so that a someone exploring repository for first time also have a clear understanding how images get built.

I don't believe it's necessary to detail the specifics of the workflow since they're quite straightforward, and the image building and publishing logic is abstracted in Makefiles. Can you point out what parts of our current workflow setup that might pose challenges or appear opaque to newcomers? I'll try to make them clearer in the document.