It’s amazing what you’ve put together in such a short time.
I used the same name for both PR pushes, but they created two different PR’s. So either we need to be able to specify a branch, or have the changes pushed to a specified existing PR.
1 Like
GitHub knows that you have forks/branches that could apply to the upstream project.
Git is structured to be able to make this work with its internal structure.
eg I might maintain a “Fission fork” and any branches there — from “main” to “Boris-minor-tweak” — could equally be applied “upstream” to the TW5 core.
As Boris mentions, that is just Github trying to being helpful, and knowing that Jeremy’s repository is the parent and you have a branch with new changes, it is suggesting to create a PR. If you check back later (tomorrow perhaps?) you wont see those messages any more.
Updating the same PR is not implemented at the moment, but it is possible but will require a bit more work. This is how far I got with missing my bed time by a couple of hours last night! @pmario and I have been discussing what it would take to also be able to update a PR over in the other thread: Edit documentation in TW and use Github API to create PRs directly? - #14 by saqimtiaz
Personally I think it would be helpful to figure out this part of the user story and workflow first, creating a new PR and how and where the user starts with a copy of tw-com. Updating PRs can come in time. The UI needs work as well and that is all wikitext work.
Hopefully there is enough there at present to inspire others to contribute towards getting this usable by others.
When I’m doing this by hand, I make changes to a branch I’ve created. Pushing the branch adds it to the current PR associated with the branch. Well, at least I thought that was what is happening.
@Mark_S understood and the process is the same, it just isn’t implemented at present and will need more work.
Getting it working so quickly meant taking a shortcut with a plugin (createPullRequest) for the base library (octokit) that works with the API. This plugin creates new PRs and makes that very easy, but abstracts away pushing to a branch so pushing to an existing branch needs to be handled directly with the low level API. As I mentioned, we have been discussing this in the other thread if you are interested in further details.
I have pushed through some quick changes, hopefully I haven’t broken anything.
I have been spending time on this that I really do not have to spare at present, so it is my hope that others will chip in to get this to a state where it is usable.
The code itself is very concise and not complex.
Changes:
- Disable “Make a PR” button and show an error message if the tiddler titles entered do not correspond to real tiddlers. Primary concern here is someone forgetting brackets around a title with spaces, which would create a broken PR, and having no way to correct it once the PR has been created.
- Use the PR title in slugified form as a prefix for the branch name.
- show rudimentary progress notifications
- made target repository configurable via config tiddler
- added some rudimentary error handling
- ensure that new files added get a
.tidextension
Note that the first time you create a PR after loading the wiki, the Octokit library is loaded on demand. This is why that first PR takes longer, a second PR created without reloading the wiki is much faster. This is implemented in this manner so that wikis that have this “plugin” do not load the libraries from the CDN until and unless they need it. If we imagined an edition that was specifically for making PRs, the libraries could also be loaded when the wiki loads.
1 Like
Demo link updated with one that updates with the latest content from tw-com every 15 minutes.
I’ve submitted my first PR to jermolene using this system. It probably has the longest branch name of any PR ever created.
It might make sense to limit the slug generated for the branch name to a max length, lest we run in to some invisible limit.
@saqimtiaz Is the demo page supposed to be fairly up-to-date? I was looking at the EditTextWidget tiddler and noticing that it predates the tiddler at TiddlyWiki .com, which was updated Oct 21.
Thanks!
It runs off the master branch which corresponds to the pre-release for TW. Currently the tiddlywiki-com branch - which is what corresponds to the tiddlywiki.com site - has changes that the master does not. @jeremyruston could we merge please?
For working on current documentation using the tiddlywiki-com branch would make more sense, and that would need a slightly different build process. I can switch that over when I find the opportunity to work on this.
One consequence for making that switch will be that it will no longer be possible to work on pre-release documentation using the same setup, though that should be a less frequent need.
OK, if I got everything right, the demo is now generated from the tiddlywiki-com branch and as such should mirror the tiddlywiki.com site. It will not include pre-release only content.
1 Like
I’ve pushed a few small improvements including a select dropdown to choose whether to create a test PR against a test repo, or a real PR against the official TW repo.
I hope this is still live, I’ve created my first docs tweak (to https://tiddlywiki.com/#Using%20Stamp)
Very clever - can see a preview of my changes at TiddlyWiki — a non-linear personal web notebook
How does tm-makepr work? Where can I read the source code?
Seems you have made a Github SyncAdaptor? Different from the Github Saver plugin, which save whole HTML to github, you can sync single diffed tiddler to the github.
See: 7 Steps to Improve the TiddlyWiki Documentation
The pr-maker is described at step 4 & 5 … Every step also has a video-tutorial, how to work with it
1 Like