Skip to content

Versioning stack artifacts

Jump to bottom
Edward Mezarina edited this page Nov 15, 2021 · 24 revisions

Update w/ Maven 0.6, Gradle 0.1

We're going to try versioning the Maven devfile + outer loop in a single release. Similarly for Gradle.

WHAT NUMBERS TO BUMP THE VERSIONS TO? INTRA-STACK REFERENCES

  1. Devfile -> Stack Image A1.B1 Docker image/tag (devfile OL version takes precedence over stack image OL, but lose out on caching)
  2. Devfile -> Outer Loop A2.B2 - GitHub Release HTTPS URL (devfile OL should match outer loop OL version)
  3. Outer Loop -> Stack Image A3.B3 Docker image/tag (No identified cases were OL version should matter)
  4. child devfile -> Parent Devfile X.Y.Z

In the future, there should be a preferred Open Liberty version that is cached in a given version of the stack image, but the version should be customizable and parameterizable on the outer loop build).

CONSUMING ARTIFACTS

4Q20 version tags

PRODUCING ARTIFACTS

  1. Commit source changes (obviously), push

  2. Submit PR, merge PR

  3. git tag xxxxx (for any/all of devfile-x.y.z, stackimage-x.y.z, outer-loop-x.y.z. which apply) Then push tag. For example:

    (from main branch)
git tag devfile-x.x.x
git push origin --tags

  4. Run build.sh (and use the locally-generated outputs as the input for creating the releases).

  5. Create GitHub releases for each of the devfile-x.y.z and/or the outer-loop-x.y.z, whichever apply. (Both are referenced by the CP4Apps pipeline, though the stackimage is not, it's only referenced via the image built from it, so the tag is sufficient for the stack image).

    • Go to https://github.com/OpenLiberty/devfile-stack/releases
    • Click "Draft new release"
    • For "Tag version" find the appropriate tag that you created before
    • Name the release the same as the tag name
    • Say what changed in the description
    • Attach appropriate files from your local "generated" directory (source zips will be automatically added once release is published)
    • Click "Publish release"

  6. (IBM team only) - For stack image build, use GHE build-java-openliberty-stack-image repo

  7. For Devfile change, PR to https://github.com/odo-devfiles/registry/

MORE DETAILS ON UPDATING ARTIFACTS

Update starter

  1. put tag in pom.xml
  2. commit
  3. tag with mentioned tag, push tag

Update devfile

  1. Increment version in devfile
  2. Send PR to https://github.com/odo-devfiles/registry/
  3. At this point it can be used unofficially as (e.g.)

    odo registry update DefaultDevfileRegistry https://github.com/scottkurz/registry

  4. Tag repo with devfile number

If this ends up being too loose, we could modify this so that we only check in x.y.z-rc1 into our own repo, and then have the PR to the official odo registry use x.y.z

REGRESSION TEST

  1. Test simple-jaxrs with no devfile
  • With hot tests
  • with debug, then odo test

Update image

  1. Update content
  2. Update devfile version, increment Dockerfile version in devfile
  3. Commit devfile referencing next tag
  4. build image with latest, major.minor, major.minor.micro

REGRESSION TEST

  1. Test simple-jaxrs with no devfile
  2. Test simple-jaxrs with specific version of devfile (but newer image)

Update intro

  1. Consider devfile registry Travis test
  2. Other odo tests?
  3. Consider if it should be merged into 'kctr' branch for CP4A Knowledge Center (try to keep fast-forwarding branch)
Clone this wiki locally