feat(releases): Allow group resolution in a future, possibly nonexistent semver release #101615
Conversation
github-actions
bot
added
the
Scope: Backend
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #101615 +/- ##
===========================================
+ Coverage 80.07% 80.98% +0.91%
===========================================
Files 8701 8700 -1
Lines 386936 386858 -78
Branches 24520 24491 -29
===========================================
+ Hits 309825 313288 +3463
+ Misses 76763 73222 -3541
Partials 348 348 |
![semgrep-code-getsentry[bot]](https://avatars.githubusercontent.com/in/1153895?s=60&v=4){kind=small}
| cls.objects.filter(group=group) | ||
| .select_related("release") | ||
| .values_list( | ||
| "type", | ||
| "release__id", | ||
| "release__version", | ||
| "release__date_added", | ||
| "current_release_version", | ||
| "future_release_version", | ||
| )[0] |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 101 lists a dependency (django) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of Django are vulnerable to Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). SQL injection in Django's ORM column aliases: when using QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), or QuerySet.extra() with dictionary expansion (**kwargs), the dictionary keys are used unescaped as SQL column aliases. On MySQL and MariaDB backends, an attacker who can influence those keys (for example, by passing a crafted dict of annotations) can inject arbitrary SQL into the generated query.
To resolve this comment:
Check if you are using Django with MySQL or MariaDB.
- If you're affected, upgrade this dependency to at least version 5.2.7 at uv.lock.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
| for i in GroupResolution.objects.filter(group__in=resolved_groups).values_list( | ||
| "group", "type", "release__version", "actor_id" | ||
| "group", "type", "release__version", "future_release_version", "actor_id" | ||
| ) |
There was a problem hiding this comment.
High severity vulnerability may affect your project—review required:
Line 665 lists a dependency (django) with a known High severity vulnerability.
ℹ️ Why this matters
Affected versions of Django are vulnerable to Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). SQL injection in Django's ORM column aliases: when using QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), or QuerySet.extra() with dictionary expansion (**kwargs), the dictionary keys are used unescaped as SQL column aliases. On MySQL and MariaDB backends, an attacker who can influence those keys (for example, by passing a crafted dict of annotations) can inject arbitrary SQL into the generated query.
To resolve this comment:
Check if you are using Django with MySQL or MariaDB.
- If you're affected, upgrade this dependency to at least version 5.2.7 at uv.lock.
- If you're not affected, comment
/fp we don't use this [condition]
💬 Ignore this finding
To ignore this, reply with:
/fp <comment>for false positive/ar <comment>for acceptable risk/other <comment>for all other reasons
You can view more details on this finding in the Semgrep AppSec Platform here.
…e_version <= new_release.version
| if not Release.is_semver_version(resolution.future_release_version): | ||
| continue | ||
|
|
||
| # If release.version >= future_release_version, clear the resolution |
There was a problem hiding this comment.
We need to parse GroupResolution.in_future_release in order to make the version comparisons. I'm not sure how to make this more efficient (lt/gt probably won't work here, right?). If we just needed to check equality it would be much simpler, but I'm assuming that:
- We have a group that will be resolved in release 2.0.0
- We skip over 2.0.0 (never release it) and instead release 2.0.1
- That group should still be marked as resolved even though 2.0.0 != 2.0.1
|
Hey it looks like awesome feature. Would it be possible to add support for a wildcards in the future releases? In our company the exact release name is not known until is released. Besides known things like the product name and version we're keeping the release date in the name.. The wildcard support would solve the problem for us. E.g if we could specify future release like |
|
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you add the label "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
relates to REPLAY-704
relates to #83696
relates to #68525
Add a new group resolution type in_future_release. Handle resolving in this type, checking for regressions, and clearing expired resolutions on the backend.
This resolution type only applies to semver releases. If we attempt to make a mixed or non-semver comparison, skip and fall back to existing logic.
I still need to add some tests ensuring that the logic stays the same for different packages--since we only care about inferring order from the semver version itself, package shouldn't matter
Next steps: add to frontend