action #25826
closed[tools][sprint 201710.2] Tag a new openQA release
0%
Description
Hi,
Could you add tags to git repo in a timely manner?
I'm trying to create debian package based on git repo, but it is tagged with old commit.
(both os-autoinst and openQA)
Updated by EDiGiacinto over 6 years ago
- Subject changed from Please add tag to git repo to [tools][sprint 201710.2] Tag a new openQA release
Tagging is planned once #23320 will be merged
Updated by szarate over 6 years ago
- Category set to Organisational
- Status changed from New to In Progress
It was agreed with cool to create tags after the sprint is closed, for now using currently the version generated by OBS for both projects. This should mark a submission to Factory, but the submission should not block the tagging.
A Changelog is present at /usr/share/openqa/public/Changelog for openQA, os-autoinst project still needs one.
Versioning is:** Major.Minor.build timestamp.commit**
We close sprints every Friday with odd week number. @henrich_debian if you need more information, please let us know!
Updated by okurz over 6 years ago
please take a look in https://progress.opensuse.org/issues/18006 for how the process can look like. I think a manual tag is a nice idea but does not relate to an automatic submission approach. We can try to combine it but rather we should improve the openQA-in-openQA tests
Updated by EDiGiacinto over 6 years ago
okurz wrote:
please take a look in https://progress.opensuse.org/issues/18006 for how the process can look like. I think a manual tag is a nice idea but does not relate to an automatic submission approach. We can try to combine it but rather we should improve the openQA-in-openQA tests
Not sure what you mean by " I think a manual tag is a nice idea but does not relate to an automatic submission approach.". I really would be scared of automatic tagging in GH - and i'd avoid that - for what git repos are concerned, imho it's better tagging it manually (since it's just a matter of using git tag and push).
But i agree that from OBS/openQA-in-openQA perspective automation looks like the way to go - as long as acceptance is done manually.
Updated by szarate over 6 years ago
please take a look in https://progress.opensuse.org/issues/18006 for how the process can look like. I think a manual tag is a nice idea but does not relate to an automatic submission approach. We can try to combine it but rather we should improve the openQA-in-openQA tests
We have talked about this in the past if I remember correctly, I mention the last time we are a bit far away from the point where a version can be released in an automated way. The automatic submission approach is another of your cool ideas, but to put it properly in motion, openQA in openQA tests need to be improved and extended to reduce the need for manual testing which I believe will always be there.
This specific issue, is about generating tags on the git repo, we decided to use the OBS project. Nothing really complicated since it's going to be consumed by other communities (as @henrich_debian comes from Debian) and if this helps them, then why not make it easier :)
Updated by henrich_debian over 6 years ago
szarate wrote:
Versioning is:** Major.Minor.build timestamp.commit**
It seems to be good for me, at least :)
Updated by okurz over 6 years ago
Sure. Also the OBS submit requests still need a review step. Within this step we could trigger even more tests by bots and feedback the result on the SR or also ask for manual acceptance. So the final release can always have a human intervening but we might still want to just create the SR automatically. And let's imagine we have that review and test workflow in place then we could even automatically create the git tag based on the last accepted SR.