Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we stop a user from creating two sidetag updates with the same sidetag #3484

Closed
ryanlerch opened this issue Aug 25, 2019 · 8 comments · Fixed by #3516
Labels
Projects

Comments

@ryanlerch
Copy link
Contributor

@ryanlerch ryanlerch commented Aug 25, 2019

Currently, it is possible for a user to create two different updates from the same sidetag. This may be an edge-case, as if the builds are the same when creating the update, bodhi will not allow the update to be created, as the builds validator detects an update already has those builds.

However, it is possible if a user pushes new builds to a sidetag, to create a new update from the same sidetag.

The discussion here is should we update the validators to determine if any existing update has the same from_tag value, and block the update from being created?

@cverna

This comment has been minimized.

Copy link
Member

@cverna cverna commented Aug 26, 2019

I would say that if an update was already created with a side tag and a packager wants to change it then it should edit the existing update. So I think that not allowing creating multiple update from the same side tag seems to be a good idea.

tagging @hroncok to see his opinion.

@hroncok

This comment has been minimized.

Copy link
Contributor

@hroncok hroncok commented Aug 26, 2019

This is more an user story question. What is the idea behind side tag updates? Will pushing to stable close the side tag, etc.? Do we have a step by step user perspective of this?

@cverna

This comment has been minimized.

Copy link
Member

@cverna cverna commented Aug 26, 2019

@hroncok oh sorry for the lack of context. A side tag update is how we will do multi build updates in rawhide. The simplified workflow is here (https://pingou.fedorapeople.org/Simplified_multi_builds_update.jpg).

@hroncok

This comment has been minimized.

Copy link
Contributor

@hroncok hroncok commented Aug 26, 2019

That picture doesn't really give that much context :D

This is what I usually do in side tag:

  1. request it
  2. build, build, build, build
  3. request it to be merged
  4. it is merged, nobody can build in it

In the bodhi world, I expect the following:

  1. request it
  2. build, build, build, build
  3. create a bodhi update with the entire side tag content
  4. update pushed, nobody can build in the side tag

If this is the expected usecase, the answer to "Should we stop a user from creating two sidetag updates with the same sidetag " is yes.

The better question IMHO is: "Should we allow an user from creating two (or more) updates from a sidetag without having all of the (most recent) builds from the side tag in that update" and a followup: "If a sidetag update exists and a new build happens in that side tag, should it be automatically added?" and if not: "Should side tag builds be allowed with pending updates, without explicit unpush of that update?"

@cverna

This comment has been minimized.

Copy link
Member

@cverna cverna commented Aug 26, 2019

That picture doesn't really give that much context :D

This is what I usually do in side tag:

1. request it

2. build, build, build, build

3. request it to be merged

4. it is merged, nobody can build in it

In the bodhi world, I expect the following:

1. request it

2. build, build, build, build

3. create a bodhi update with the entire side tag content

4. update pushed, nobody can build in the side tag

If this is the expected usecase, the answer to "Should we stop a user from creating two sidetag updates with the same sidetag " is yes.

Yes that is the expected workflow.

The better question IMHO is: "Should we allow an user from creating two (or more) updates from a sidetag without having all of the (most recent) builds from the side tag in that update"

Hum yes that's a good point.

and a followup: "If a sidetag update exists and a new build happens in that side tag, should it be automatically added?" and if not: "Should side tag builds be allowed with pending updates, without explicit unpush of that update?"

Yes also good questions, in the discussion we had we expect the packager to edit the update in the case where it is needed to add a new build to an already existing update.

tagging @pypingou so he is aware of the questions you have raised.

@hroncok

This comment has been minimized.

Copy link
Contributor

@hroncok hroncok commented Aug 26, 2019

I guess it is OK to require the packager to edit the update in order to add new builds. In that case please make it easy to add all new builds. My last side tag has something between 2000 and 3000 packages.

I think having a strict 1:1 relationship between a side tag an and update is the only reasonable way. Aka we don't want multiple updates from within one side tags and we don't want one update to contain builds from multiple side tags (that might work, but is very fragile IMHO).

@ryanlerch ryanlerch added this to To do in CI Gating via automation Aug 27, 2019
@pypingou

This comment has been minimized.

Copy link
Member

@pypingou pypingou commented Aug 28, 2019

I think having a strict 1:1 relationship between a side tag an and update is the only reasonable way. Aka we don't want multiple updates from within one side tags and we don't want one update to contain builds from multiple side tags (that might work, but is very fragile IMHO).

👍

@pypingou

This comment has been minimized.

Copy link
Member

@pypingou pypingou commented Aug 28, 2019

If a sidetag update exists and a new build happens in that side tag, should it be automatically added?

So far we were thinking: "No but it would prevent the side-tag from being merged (since not all builds are in the update and thus not all builds have been tested"

Should side tag builds be allowed with pending updates, without explicit unpush of that update?

If we make sure to prevent merging side-tags where not all builds are included in the update, I think we don't need this extra step.

@ryanlerch ryanlerch moved this from To do to In progress in CI Gating Sep 25, 2019
ryanlerch added a commit to ryanlerch/bodhi that referenced this issue Sep 25, 2019
previously, a user was able to create an update
from a sidetag that was already used in an existing
update. this commit adds a validation check to make
sure a user cannot create an update from a side tag
that is already used in an update.

fixes: fedora-infra#3484

Signed-off-by: Ryan Lerch <rlerch@redhat.com>
@ryanlerch ryanlerch moved this from In progress to Need Review in CI Gating Sep 25, 2019
ryanlerch added a commit to ryanlerch/bodhi that referenced this issue Sep 25, 2019
previously, a user was able to create an update
from a sidetag that was already used in an existing
update. this commit adds a validation check to make
sure a user cannot create an update from a side tag
that is already used in an update.

fixes: fedora-infra#3484

Signed-off-by: Ryan Lerch <rlerch@redhat.com>
@mergify mergify bot closed this in #3516 Sep 26, 2019
CI Gating automation moved this from Need Review to Merged to develop Sep 26, 2019
mergify bot added a commit that referenced this issue Sep 26, 2019
previously, a user was able to create an update
from a sidetag that was already used in an existing
update. this commit adds a validation check to make
sure a user cannot create an update from a side tag
that is already used in an update.

fixes: #3484

Signed-off-by: Ryan Lerch <rlerch@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
CI Gating
  
Merged to develop
4 participants
You can’t perform that action at this time.