Zenodo2023

[aborel]

This pull requests updates the Zenodo web translator to work with the new InvenioRDM platform https://blog.zenodo.org/2023/10/13/2023-10-13-zenodo-rdm/

DOM selectors have been modified to match the new structure, and the tests have been updated due to minor JSON changes in Zenodo.

[dstillman]

This looks great, but could you rebase this on current master and force-push for a cleaner commit log in this PR?

[aborel]

I thought I had rebased my repo, but if it wasn't done properly I'll fix it.
Thanks for the force-push info, I felt that something should be done there, but I didn't know what. Will do.

[aborel]

Certainly better now, I hope it's enough.

[dstillman]

No, you can see it still says above that there are 94 commits in this PR, by you and others. You'll want to fetch the upstream master (i.e., master in this repo), rebase your zenodo2023 feature branch on that, and force-push, which will leave just your new commits showing in this PR.

[aborel]

Sorry if it's a naive question, but I think I am quite confused about this step. I understand that the PR needs to contain only the 11 relevant commits for the one modified file, but currently I am stuck trying to get rid of the unnecessary details of a previous PR. I have been following the procedure described by https://medium.com/@topspinj/how-to-git-rebase-into-a-forked-repo-c9f05e821c8a but is complaining about conflicts regarding the old project that was closed weeks ago, but I don't understand how to just move on and ignore these. This is my second PR ever, so I am still learning the good practices... can you enlighten me?

[dstillman]

Hard to help without knowing the exact history of your feature branch, but in this case you can just make a copy of this file outside the folder, do git fetch upstream master followed by git reset --hard upstream/master (which will delete all changes), copy the file back, make a new commit with just that file, and force-push. (This is assuming upstream is this repo, which you can see with git remote -v. If origin is this repo, use that instead for both commands.)

[dstillman]

In general, for a PR, you would make sure you were always starting a feature branch from a freshly fetched copy of upstream/master (either literally upstream/master or just master if you're pulling it to a local branch). Then if you ever had to rebase, you would fetch upstream/master or pull it into your local master and rebase -i the feature branch on that. You would never want to start a feature branch from a branch that wasn't the latest commit in this repo.

[aborel]

I guess my original mistake was to work on the old project in my master branch. I tried to be smarter this time, but apparently I'm still carrying the burden of that unfortunate decision.
Let's see if I understand how to fix this: is there a clean way to rebase my master branch (or otherwise reset it, if that's not the correct git operation) and merge it into the new zenodo2023 feature branch?

[dstillman]

You should just do what I said above. It's just a single file.

[aborel]

Hum. I think a I have rebased a bit too far and lost my actual commits, even in my own repo (my saved copy of Zenodo.js wasn't the version I wanted... sigh).
Unless my code is somewhere in github limbo, I will need to rewrite everything (it wasn't super complicated, I should be able to reproduce it all). Unless that's the wrong thing to do, I will open a new PR when I'm done. Sorry about all that!

[dstillman]

This?

Zenodo.js.zip

[aborel]

Yes, that's the one :-) Thank you so much!

[aborel]

Can you re-open the PR? My branch is still there, it looks properly rebased, and I have committed the new file (with just one more minor change).
It shouldn't have been so hard for me to do what was asked, but I really wasn't seeing where I was going. Thanks for your patience!

[dstillman]

Thank you!