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

fix(backend-github): prepend collection name #2878

Merged

Conversation

barthc
Copy link
Contributor

@barthc barthc commented Nov 13, 2019

Summary
Closes #2620, closes #1933, closes #1396

@erquhart
Copy link
Contributor

erquhart commented Nov 14, 2019

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.

@erquhart erquhart requested a review from erezrokah November 14, 2019 03:10
@erezrokah
Copy link
Contributor

erezrokah commented Nov 14, 2019

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 listUnpublishedBranches - we already get all the cms/ branches, we can get their metadata (or even use labels to mark the ones that have been migrated like suggested here: #1669).

Then we can rename the existing branches and update any relevant metadata.
The plus side it will fix those issues for existing branches as well.

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.

@barthc
Copy link
Contributor Author

barthc commented Nov 14, 2019

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.

@erezrokah
Copy link
Contributor

Good points @barthc, I'll have time to take a closer look once I'm done with #2851

@erquhart
Copy link
Contributor

erquhart commented Nov 17, 2019

Creating a new branch and deleting the old should do the trick for renaming.

Sent with GitHawk

@barthc barthc force-pushed the fix/github-backend-prepend-collection-name-to-branch-name branch from e07f610 to 232de41 Compare November 18, 2019 10:50
@erezrokah
Copy link
Contributor

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([
Copy link
Contributor Author

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.

Copy link
Contributor

@erezrokah erezrokah Nov 19, 2019

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.

@erezrokah
Copy link
Contributor

Just noticed you ported the migration code. Nice one :)
I do have a bug in my branch where I don't set the metadata current version when persisting metadata.
I'll try to go over your recent changes soon

@@ -225,6 +224,29 @@ export default class API {
);
}

deleteMetadata(key) {
Copy link
Contributor

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 => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the async required?

Copy link
Contributor Author

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.

@barthc
Copy link
Contributor Author

barthc commented Nov 19, 2019

I do have a bug in my branch where I don't set the metadata current version when persisting metadata.

Yes I added that in.

@erezrokah
Copy link
Contributor

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.
We still want the migration code to work, even if the implementation of the key/branch generation changes in the future.

I'm good with merging if you are.

@barthc
Copy link
Contributor Author

barthc commented Nov 20, 2019

@erezrokah thanks for the changes. I think we forgot to handle one edge case. I will push up shortly.

@erezrokah
Copy link
Contributor

erezrokah commented Nov 20, 2019

Cool, I'm pushing a fix for the GraphQL createBranch too (it should return an object with a ref property).

const entriesLoaded = get(state.editorialWorkflow.toJS(), 'pages.ids', false);
//run possible unpublishedEntries migration
if (!entriesLoaded) {
const response = await backend.unpublishedEntries(state.collections).catch(() => false);
Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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);
Copy link
Contributor Author

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.

@barthc
Copy link
Contributor Author

barthc commented Nov 20, 2019

@erezrokah did you find the PR @erquhart referenced above?

head: pr.head.sha,
},
branch: newBranchName,
version: CURRENT_METADATA_VERSION,
Copy link
Contributor

@erezrokah erezrokah Nov 20, 2019

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:

  1. Migrating from no version to version 1, then to version 2.
  2. Migrating from version 1 to version 2.

The migrateBranch method will run migrations serially based on the current version and metadata version.

Copy link
Contributor Author

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.

@erezrokah
Copy link
Contributor

Again, great job @barthc! Going to let @erquhart have a look at this before merging just to be sure.

@erezrokah
Copy link
Contributor

@erezrokah did you find the PR @erquhart referenced above?

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.

@erezrokah
Copy link
Contributor

Going to push this through as we have some more changes coming to the GitHub API

@erezrokah erezrokah merged commit 465f463 into master Nov 26, 2019
@erezrokah erezrokah deleted the fix/github-backend-prepend-collection-name-to-branch-name branch November 28, 2019 07:02
nathankitchen pushed a commit to nathankitchen/netlify-cms-backend-azure that referenced this pull request Feb 24, 2020
* 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
vladdu pushed a commit to vladdu/netlify-cms that referenced this pull request Jan 26, 2021
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants