I agree, updating the website is a lot more complicated than it should
be. However, the site branch is necessary because it's used to publish
changes that must be visible on the site immediately. There are changes
such as documentation for new features, etc that should not be published
immediately, so we don't cherry-pick them into the site branch.
So, in summary:
- Changes to the website should always be committed to master.
- If the change must be visible right now, cherry pick the commit into
the site branch.
- Once a final release of Calcite has been tagged, reset the site branch
to master: git reset --hard master
From personal experience, it's the building and committing of the
generated website files that is the most troublesome. Due to slightly
different versions of Jekyll and timezones, the generated files might
change slightly and a simple update to the website generates a cascade
of changes across files that were not touched during the editing
process. There is then the challenge of pulling down the calcite-site
repo and merging those changes in, while being careful not to delete
things like the javadocs.
I am almost very close to getting the automated website builds sorted. I
was in contact with infra last month to get the token to push to
calcite-site added to our Github Actions secrets and will ping them
again this week. Once automated website builds are implemented, editing
the website should be as easy as:
- Run "docker-compose run --service-ports dev" to start a docker
container for live reloading.
- Make your changes.
- Visit http://localhost:4000 and reload the page as you make changes to
see the results.
- Commit your changes.
- If the change needs to be published immediately, cherry-pick the
commit into the site branch and push.
Vladimir, as part of the release process, the site branch and the master
branch should be even once a final release is tagged. This ensures that
any changes to the site that were not published previously because they
relate to changes in the code base would finally be published. Do you
think it would be feasible to update the publishDist gradle task to even
the site and master branches using git reset --hard master?
Francis
On 8/12/2019 8:19 pm, Vladimir Sitnikov wrote:
As I was trying to update the website recently I noticed that there is a
mixture of all kind of commits
The same goes for me.
The rebase-cherrypick dance seems to be more complicated than it should.
Vladimir
