Workflow: build ags4 docs #285
Conversation
preliminary version
|
How are the artifacts named? I can't pickup from the change |
|
If I can believe the job summary, the new artifacts are like this: |
|
ok, re-reading now, what I see in the previous build it has uploaded the artifacts before, then it runs the ags4 version of things and uploads new artifacts. It would be better if the ags-help.chm was renamed to The other thing is that currently the release of the website will just publish the web build artifact that was uploaded, so it will need an intermediate step to add a new ags4 subfolder and create a new artifact from the previous two. I am more commenting that as is, this doesn't publish any artifact to a release that can be consumed from the main ags repository. |
|
Right, I didn't pay attention to the release script. So we download from the release files rather than the artifacts, right? The web version needs more work, I need to add a version selector, build the correct folder structure, possibly also enact the redirection from current urls to explicit version subfolder. Still not there yet. |
|
Looks alright now. We can change the how it accomplishes this workflow later if we want, as long we keep the release assets with the same name. Once this is merged, the ags4 branch in AGS main repository needs to fetch this specific one in cirrus CI and rename it as only ags-help.chm and it should all workout. |
|
Alright then, on to the next step. |
|
Something broke with the edit link somehow, see the commit below. Also, for some reason the github page got deployed twice? Erh, running locally, I tried Edit: it doesn't work because the submodule has a specific commit and not a specific branch I think. This would work if it was a regular branch that was git cloned. Edit2: perhaps a possible fix would be to scrap the git submodule altogether for now and put a git clone command that creates source in the |
|
Made the change to the ags4 branch in main repository |
God forsaken submodules... I'm using a github action to clone the repository, I actually wanted to use a bash if directory exist, to then shallow clone with both branches. Of course it keeled over with error code 128, so I gave up and let checkout@v4 do the task, |
|
Yeah, that should work fine. The error 128 is from GitHub web somehow or this is a git thing? I need to check it out. One thing with submodules is that often I fall in an issue where I can't solve with any git command I am used in my computer and then I need to delete the folder (like ags-manual not source) an reclone it. Like, when the submodule source changed from the wiki, it never changed locally for me and when they desynced I started getting "failed to find commit errors", and then it turned out that it was using the wrong remote url for the submodule even through was supposed to be in the correct one, so delete the and reclone it I went. |
|
I don't know, maybe I had forgotten to remove the source folder from the repo, but there was no error to be seen from the web log, so I lost my patience. EDIT: Never mind, mountain excursion canceled. |
2 participants
Preliminary version.
Perhaps it's possible to remove repetition with reusable workflows. I just read they exist, so I don't really know possible issues yet.
Each run could clean up after uploading the artifacts, would just need to add a prefix to them.
Note: I'm not fetching specific versions of the ags4 branch, but arguably this whole sync thing is just a mechanic to waste our time.
There will never be a case in which we build an older manual through the CI. We might as well just always get the latest both on ags3 and 4 doc sources.
Unless anyone's got time to improve on this, we could merge and start using the ags4 artifacts for ags4 builds.
Though the v4 manual is still a WIP, I added almost all apis.
Next step will be figuring out the multiversion web manual.