-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
fix(backend-github): prepend collection name #2878
fix(backend-github): prepend collection name #2878
Conversation
Thanks @barthc! Since Erez has a PR open that touches the workflow a lot I'm going to defer to him for review. I do remember a PR like this getting merged in the past (from someone else, not you), and I believe it caused some issues and had to be reverted. I'll see if I can find it. |
I like the new approach, but instead of baking in backwards compatibility into several different API methods, how about doing one single migrate operation? A possible place to do it is in Then we can rename the existing branches and update any relevant metadata. Update: I think it will also be a bit easier to test - we just need to make sure the migration process works instead of testing different API methods, each one for the old/new way of creating branches. Another update: might be a good opportunity to introduce some versioning scheme for metadata to make it easier to migrate in the future. |
I was thinking with this approach(backwards compatible), we can drop searching for the old key sometime in the future. Regarding migration, I believe we discussed something like so in another PR. One of the issues is that we can't delete or rename(maybe not sure) any metadata file inside the orphaned branch. So the best we can do is duplicate the metadata file with the new key name. I also don't think we can rename branch via the api. |
Creating a new branch and deleting the old should do the trick for renaming. Sent with GitHawk |
e07f610
to
232de41
Compare
How about something like this: b37faa0 I cleaned up some of the code for getting unpublished branches, but the relevant migration code is here: b37faa0#diff-b4ba42c688a23ed9cec5139daec2c157R452 It needs some more testing (manual and automatic) and some code cleanup though. |
const onlyBranchesWithOpenPRs = filterPromisesWith(({ ref }) => | ||
this.branchHasPR({ branchName: this.branchNameFromRef(ref), state: 'open' }), | ||
); | ||
const onlyBranchesWithOpenPRs = flowAsync([ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Used a new flowAsync
utility function, which is cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see here:
b37faa0#diff-b4ba42c688a23ed9cec5139daec2c157R518
Instead of sending a pulls
API request per branch and since that API uses substring match, we can send a single request with cms
as the matching pattern and filter the branches according to the result.
Just noticed you ported the migration code. Nice one :) |
@@ -225,6 +224,29 @@ export default class API { | |||
); | |||
} | |||
|
|||
deleteMetadata(key) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
@@ -387,8 +387,8 @@ export default class GitHub { | |||
const promises = []; | |||
branches.map(({ ref }) => { | |||
promises.push( | |||
new Promise(resolve => { | |||
const contentKey = ref.split('refs/heads/cms/').pop(); | |||
new Promise(async resolve => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the async
required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I forgot to remove that.
Yes I added that in. |
Hey @barthc. I added some unit tests, re-recorded the e2e tests data and made some code changes, the most notable one is to hard code the migration code. I'm good with merging if you are. |
@erezrokah thanks for the changes. I think we forgot to handle one edge case. I will push up shortly. |
Cool, I'm pushing a fix for the GraphQL |
const entriesLoaded = get(state.editorialWorkflow.toJS(), 'pages.ids', false); | ||
//run possible unpublishedEntries migration | ||
if (!entriesLoaded) { | ||
const response = await backend.unpublishedEntries(state.collections).catch(() => false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For published entry that have a draft entry, let's run the migration code first before loading the draft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can happen when opening an entry in edit mode directly without going through the workflow tab first? Am I correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's correct.
const backend = currentBackend(state.config); | ||
const entriesLoaded = get(state.editorialWorkflow.toJS(), 'pages.ids', false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The unpublished entries(workflow page) should now load only once.
@erezrokah did you find the PR @erquhart referenced above? |
head: pr.head.sha, | ||
}, | ||
branch: newBranchName, | ||
version: CURRENT_METADATA_VERSION, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be hard coded to '1' since we don't want it to change when someone updates CURRENT_METADATA_VERSION
(see comment at the beginning of the method).
e.g. let's say we have at some point CURRENT_METADATA_VERSION = 2
, we would have two scenarios:
- Migrating from no version to version 1, then to version 2.
- Migrating from version 1 to version 2.
The migrateBranch
method will run migrations serially based on the current version and metadata version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I will remove it.
Just saw this comment. Didn't find the PR, but we've discussed it and we're getting confident about merging this. Just letting @erquhart express his opinion the migration code first then it will be good to go. |
Going to push this through as we have some more changes coming to the GitHub API |
* fix(backend-github): prepend collection name * chore: prefer migrating entries * chore: cleanup * chore: move migration to listUnpublishedBranches * chore: prefer flowAsync * chore: feedback updates * refactor: extract current metadata version to a const * refactor: don't send pulls request on open authoring * test: update recorded data * fix: hardcode migration key/branch logic * test(backend-github): add unit tests for migration code * fix(github-graphql): add ref property to result of createBranch * test(cypress): update recorded data * fix: load unpublished entries once * fix: run migration for published draft entry * fix: failing test * chore: use hardcoded version number * fix: use hardcoded version number * test(cypress): update recorded data
* fix(backend-github): prepend collection name * chore: prefer migrating entries * chore: cleanup * chore: move migration to listUnpublishedBranches * chore: prefer flowAsync * chore: feedback updates * refactor: extract current metadata version to a const * refactor: don't send pulls request on open authoring * test: update recorded data * fix: hardcode migration key/branch logic * test(backend-github): add unit tests for migration code * fix(github-graphql): add ref property to result of createBranch * test(cypress): update recorded data * fix: load unpublished entries once * fix: run migration for published draft entry * fix: failing test * chore: use hardcoded version number * fix: use hardcoded version number * test(cypress): update recorded data
Summary
Closes #2620, closes #1933, closes #1396