Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyOOM-500

Raw notes from 20180202 - scheduling a PTL meet for after the vF2F

20180202 Notes:
- Alexis, Marco proposal;
1) which docker tag set to test - latest or timestamp based?
Action: could force either on teams
2) how do we report -1 failure of CD - check docker merge build tag version
(leave how to fix - original tagset or latest tagset to the teams)


tag once on image production -


Discussion
- central/integration uses released docker manifest - known tested as good
- team declares a released manifest version as good (for now manually by team - later after the CD has marked the version as tested)
- component teams deploy using their snapshot + same released docker manifest for other teams' docker

Proposal: follow nexus.onap.org naming
- latest uses snapshot - follow maven format
staging
https://nexus.onap.org/#view-repositories;staging~browsestorage
name-1.2.0

snapshot
https://nexus.onap.org/#view-repositories;snapshots~browsestorage
name-1.2.0-timestamp

proposal: use symantic version v1.1.1 - is released (no latest tag) - unchanged
1.1.2-snapshot is the next under test
1.1.2-timestamp (here we need LF to pick up the format)
proposal: Timestamp-yyyy-mm-dd-Thh-mm-ssZ
or version-yyyymmddThhmmssZ (no :)
1.1.2-20181231T234559Z
fill out and merge Gildas slides
to
https://wiki.onap.org/display/DW/Independent+Versioning+and+Release+Process#IndependentVersioningandReleaseProcess-StandardizedDockerTagging
send mail to discuss and meeting 2nd monday


1.1.2-snapshot - points to the "latest" of 1.1.2-timestamp - (are the versions under continuous testing - CD is here)
developers working together can override ext components "v1.1.1" and pick whatever 1.1.2-snapshot to use" - need to see how teams use the staging/snapshot version

fully validated 


observation
- teams only have visibility on changes marked in the manifest file - not "in-development" merges
- we will likely need to group commits under test (lack of resources) - developers will need to triage together a test set that marked (n) commits in a timeframe as breaking CD
-

References