Project

General

Profile

Actions

action #41846

closed

Link version to a possible deployed delta

Added by szarate over 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
2018-10-01
Due date:
% Done:

0%

Estimated time:

Description

Currently at the end of the page the version number is displayed, it contains a hash that points to what has been deployed.

There's a suggestion from Seba that we could link to the delployed delta, initially pointing to a .md file would work, that could keep the same structure as our current deployment schedule.


Related issues 1 (0 open1 closed)

Related to openQA Infrastructure - action #55301: semi-automatic deployments on osdResolvedokurz2019-08-09

Actions
Actions #1

Updated by szarate over 5 years ago

  • Subject changed from Link version to a possible delta to Link version to a possible deployed delta
Actions #2

Updated by okurz over 5 years ago

szarate wrote:

[…] pointing to a .md file would work, that could keep the same structure as our current deployment schedule.

That wiki page was not updated for a year. How is it supposed to work differently now? And also: As long as we are talking about an osd-only solution I doubt the real need of QA engineers would be sufficiently adressed. How about an automatic email to the mailing list triggered by salt/deployment-script?

Actions #3

Updated by szarate over 5 years ago

@okurz Email comes naturally after everything is done.

The idea of the link to a delta fits into an automated deploy, which chould generate the information and publish it, no human needed :).

In any case, the solution should be kind of agnostic or as agnostic as possible, so that it can be used with other deployments. Pretty much like the changelog feature that we have... (That nobody uses)

Actions #4

Updated by okurz over 5 years ago

szarate wrote:

The idea of the link to a delta fits into an automated deploy, which chould generate the information and publish it, no human needed :).

Certainly. Take for example the automatic submit requests to openSUSE Factory that are created based on the openQA-in-openQA tests, e.g. https://build.opensuse.org/request/show/639153 which already provides a changelog. When we would ensure to update automatically to each new tested version then the changelog in the submit request would be equivalent to the changelog of what got deployed, problem solved :)

Actions #5

Updated by coolo over 5 years ago

  • Project changed from openQA Project to openQA Infrastructure
  • Category deleted (168)
Actions #6

Updated by okurz over 4 years ago

  • Related to action #55301: semi-automatic deployments on osd added
Actions #7

Updated by okurz over 4 years ago

  • Status changed from New to Resolved
  • Assignee set to okurz

As described on https://confluence.suse.com/pages/viewpage.action?pageId=194052156 as well we decided to do weekly deployments, if not more, and for now use a semi-automatic approach, potentially moving to fully automatic later on as we already have on o3. With this the need for a changelog delta is easier to get from e.g. https://gitlab.suse.de/openqa/osd-deployment/pipelines showing the changelog if the deployment was conducted successfully.

Actions #8

Updated by coolo over 4 years ago

  • Target version changed from Ready to Done
Actions

Also available in: Atom PDF