Build system changes #721
Build system changes #721
Conversation
|
Looks nice and clean, I like it. It does create a dependency on Tangentially related thing, since we are talking about releases. Do you have any suggestions for a good branch structure for hotfixes? Right now code flows from Interesting things happen, however when something needs to be hotfixed, since now we are potentially cherry-picking random commits from |
This would affect what is done with the ext/manifest.json file, which may or may not be a good idea. Basically, it creates a chicken/egg problem, where to create a commit to update the version number, build must be called, and then the commit is created (and version tagged). But if the version number is tagged in a future commit, the version number wouldn't be updated, or the version tag would be placed on the incorrect commit (off by one). The alternative would be to use a placeholder version number for the development version manifest (0.0.0.0), or to make that manifest file not tracked altogether. IMO it's probably best, for now at least, to do that part manually.
One possible option could be to consider dropping the testing branch altogether, and just have a new branch for each release. The core release would branch directly off of the master branch: git checkout master
git checkout -b release/1.2.3.0
git tag -a 1.2.3.0 -m 1.2.3.0And hotfix branches would follow this type of command flow: git checkout v1.2.3.0
git checkout -b release/1.2.3.1
git cherry-pick <commits-on-master>
git tag -a 1.2.3.1 -m 1.2.3.1This would make the non-hotfix releases always have a shared history with master, with no divergences. Hotfix branches would only diverge at the cherrry-picks, and all chains of hotfixes would share the same history (i.e 1.2.3.4 branched from 1.2.3.3, branched from 1.2.3.2, etc.) This might technically lose the ability to determine whether a current release/* branch is on testing or stable, but that may not be a big issue, since that typically only lasts a week. And even with the way it is currently done, we can't look into the past as to where the testing branch was on a certain date. I guess overall, omitting the global testing/release branch would avoid the need to change their history for releases, since new branches would exist for each release. This may add branch clutter or redundancies with the tags, so if that's a concern, the same thing could effectively be done by only using/pushing tags instead of branches. |
|
Makes sense, I like the idea of just having branches for each release. Will have a lot of branches, but who cares -- it makes it very easy to reason about what is going on and to apply hotfixes. Let's try that going forward. Maybe when branches get really old, we can go through and clean some of them up. |
|
Github will also categorize branches as "stale" when they haven't been used for a while, so there's that as well. For example, you can look at my clone, which I've never deleted any branches on: https://github.com/toasted-nutbread/yomichan/branches |
|
9e4c142 adds a test to ensure that the manifest data is updated properly, which the continuous integration will run. |
The intent of this change is to set up build system which is simple yet flexible enough to accommodate future needs (example). This can hopefully remove the need to have the testing and master branch history be divergent as it currently is; I think the reason behind that is so that the manifest.json metadata can be different on both branches.
I am requesting @FooSoft to review this, as you are in charge of creating and deploying builds. I want to make sure any changes I make will still work for your release workflow, and I can make changes as necessary.
manifest.json style updated to use standard format as output by
JSON.stringify, for simplicity. This mainly involved some newline and indentation changes, and the"author"field was moved to the top for better organization.Changed end-of-line convention for some files, for better consistency across different operating systems and development environments.
Created a simple build.js script, which creates build variants. Currently, it creates four files:
Currently, there is no difference in the contents of the zip files except for the manifest. Certain modifications are made to the manifest based on the build target. Currently, this just changes the
name,description, andapplications.gecko.idfields, but in the future, this may do other modifications as well (including/omitting files, manifest v2, browser-specific builds).The *.xpi files are copies of their .zip counterparts, which are helpful for testing Firefox builds on certain devices which don't like using .zip files.
Builds are created using 7-zip (either 7za or 7z executable), the same as the old build_zip.sh file. If neither executable is available, the build system falls back to building using the included JSZip library. Note that when JSZip is used, the resulting file size is a bit larger.
Builds are created in a "builds" directory, which is ignored by git.
Added build commands. The following can be used:
node ./dev/build.js(use \ slash on Windows)npm run-script build./build.sh.\build.batRemoved build_zip.sh, as new build commands should be used instead.
Potential downsides
The extension manifest data now exists in two locations: the standard manifest.json, and the build script's manifest-variants.json. This creates a redundancy which could be confusing and maybe a cause of developer error (putting changes in the wrong file). The manifest file that should be changed is the manifest-variants.json one, which then propagates its changes to the main manifest.json upon building. When changing the manifest, both changes should be made in the same commit (or PR).
There should be some red flags if something is not done correctly, such as git listing diffs that the developer didn't explicitly make. That is, if a change is made to manifest.json and committed, a subsequent
buildcommand will revert that, indicating that something was done wrong.So this isn't really a problem per se, just something that has to be known about in order to make updates correctly. At some point, I may add a development guidelines and information file to the project to address things like this.