In the coming weeks we’ll be changing how the door43.org project pages are processed and built.
The primary change is that we will no longer keep historical builds of the door43.org pages. Of course, the historical data is kept in DCS just like always.
On the new pages you’ll notice that the Revisions sidebar is gone and instead there is a Version drop down at the top.
Notice the following:
- The Revisions sidebar is gone but there is a Version drop down at the top.
- Notice that you can see the master branch and a version 1 release that this project has made (not all projects have releases, but you can make them by following Create a New Release - Door43 - Door43 Forum).
Normally, when you click the Preview button from the DCS project page (like test_user/en_test_tit_book: tc-desktop: en_test_tit_book - en_test_tit_book - Door43 Content Service) then you will be taken to the most recent build on the
master branch. This will fix a long standing issue where you often are taken to a previous build of the project and it’s hard to find the latest one.
An important feature of this change is that you can now persistently link to a named release (or version). For example, the “v1” page seen above will persist for the project’s lifetime and can be referenced by other sites or services. This allows work in progress to continue on the project without affecting previously published material.
Another feature created by this change is the ability to preview a branch that you may be working on. Many of our projects follow the Protected Branch Workflow - Door43 - Door43 Forum, which allows you to make changes in a branch in a project. In this new set up you will be able to see the change that you have made in a dedicated branch on the site. For example, notice the proofreading branch in the screenshot below:
This creates an easy way to preview your changes before they get merged into the main branch of the project.
In addition to simplifying how the pages work, this also paves the way for adding PDF generation to the project pages, stay tuned for this in the coming months
If you want to know technical details about this change, read on. To explain the changes it will be helpful to use an example repository. I’m going to use this as the example URL: English: test - Bible.
At the time of writing, the system works like this:
- English: test - Bible redirects to the latest commit hash, at the moment that is English: test - Bible – this redirect process is prone to several caching abstractions which makes this a frustrating process, but it “mostly works”.
- Each “save” (commit hash) page persists indefinitely
- No branches or release tags are generated, only the most recent “save” (git push) to the master branch ever gets built
Reference the first screenshot in this post and example project above. Note the following:
- ALL previous commit hash URLs (like 229e76e78b/ in the example above) will be setup to redirect to master/ .
- Any pre-existing links to old commit hashes will still work, they’ll be redirected to the latest master/ build. However, the historical build content will not be preserved. If an old commit is needed, it can either be tagged as a release or it could be checked out as a branch in the repository. Either way would generate a specific link to that historical build.
- The latest push for each active branch or release tag will persist at it’s named location
- By default, master/ will be there
- Creating a new branch, like “my_work” will show up at my_work/ and will be accessible from a drop down menu.
- Creating a release tag, like “v12” will also show up at v12/ and will be accessible from a drop down menu.