You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What are you running on?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
Expected behaviour?
The ID should not get reset when importing.
Actual behaviour?
The ID gets reset when importing.
Steps to reproduce?
Add remote location
Select GitHub gist
Don't enter an ID (which will create a new gist)
Add location
Export to the location
This will set the ID
Import from the location
The ID will be reset back to blank
This is happening because the ID for new gists is only getting created after we export for the first time, as this is the action that creates the gist. This means that the configuration that is actually saved in the gist doesn't have an ID.
The ID is returned in the response from the first export and set in the local state. This is why importing from the gist without exporting to it again results in the ID getting reset to blank, as that is the ID saved in the gist.
This is likely to be a problem for GitLab snippets as well.
Possible fixes 🤔
Some potential ideas to fix, in no particular order!
Create new gists/snippets when adding the location so we always have an ID
The gist/snippet would just be empty until the user exported for the first time
Decouple creating the gist/snippet from uploading the configuration when exporting
Similar to the above option, but only done when the user triggers an export rather than on adding
If we are exporting to a new gist/snippet we could trigger another export to make sure the saved configuration contains the ID
Stop overwriting IDs when merging imported configuration in the reducer
The re-render from changing the redux state triggers before the navigation to the success page.
Meaning the location isn't found and the remote location page code triggered a navigation to the backup page cancelling the navigation to the success page.
Refs: #347
Bug report
Nevergreen version?
v7.0.0+3503.814c359 Razzmatazz
What are you running on?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
Expected behaviour?
The ID should not get reset when importing.
Actual behaviour?
The ID gets reset when importing.
Steps to reproduce?
This is happening because the ID for new gists is only getting created after we export for the first time, as this is the action that creates the gist. This means that the configuration that is actually saved in the gist doesn't have an ID.
The ID is returned in the response from the first export and set in the local state. This is why importing from the gist without exporting to it again results in the ID getting reset to blank, as that is the ID saved in the gist.
This is likely to be a problem for GitLab snippets as well.
Possible fixes 🤔
Some potential ideas to fix, in no particular order!
The text was updated successfully, but these errors were encountered: