As a CLI user, I can edit the list of builds in an update #3037
Assignees
Comments
bowlofeggs
added
EasyFix
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 22, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 25, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 26, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 28, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Feb 28, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 1, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 4, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
bowlofeggs
added a commit
to bowlofeggs/bodhi
that referenced
this issue
Mar 13, 2019
The updates.title field used to be a space separated list of the builds found in the update, with a uniqueness constraint. There were at least two problems with it. One problem was that the list of builds was not consistently updated (fedora-infra#1946) and sometimes the title did not reflect the current set of builds in the update. This was more severe than it may seem, because it turns out that the CLI was using the title to set the list of builds when editing updates, instead of using the list of builds. This means that the CLI could set the list of builds back to a former set, rather than leaving it at the set it was currently at. Note that the CLI does not currently support editing the set of builds on an update (fedora-infra#3037), so it is especially surprising when this happens. The second problem is that large updates with many builds end up generating a very long title and PostgreSQL raises an error because it refuses to index strings beyond a certain length. It was found, for example, that release engineering could not create an update with 300 builds in it. Since we plan to use Bodhi to work with side tags as part of gating Fedora Rawhide, it will be important for users to be able to create updates with large numbers of builds. The title was also not a particularly useful field. It was possible to use it as a key to access an update, but that was a poor use for it since the title changes when the list of builds change, and because the order of the list of builds was important. This led to unpredictable and unstable URLs for updates, and Bodhi already had an update alias field which is stable and is better suited for that purpose. This commit drops the field from the database and removes it from being used to reference updates in the API. It preserves it in API responses, however, but now generates it dynamically so that the title is always an accurate list of the builds included in the update. fixes fedora-infra#186 fixes fedora-infra#1542 fixes fedora-infra#1714 fixes fedora-infra#1946 Signed-off-by: Randy Barlow <[email protected]>
|
Pull request for this option |
|
Pull request has been merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just noticed that
bodhi updates editdoes not let you add or remove builds from an update. We should give it the ability to alter the set of builds on an update.The text was updated successfully, but these errors were encountered: