spdx-spec
spdx-spec copied to clipboard
Update publish_v3.yml to alias "v3.0" (and later "v3.0.1") as "latest"
.github/workflows/publish_v3.yml:
- Update
aliasargument formike deployto havev3.0as thelatestv3.0was aliased asv3-draft, sov2.3still occupied thelatestalias.
mkdocs.yml:
mikesection: Addcanonical_versionconfiguration aslatest- This will help the
latestappear near the first in search engine, among other versions, see https://github.com/jimporter/mike#configuration
- This will help the
Will fix #949
@licquia - could you do a quick review
@bact @licquia - note the related PR #934 - can we combine these into one PR?
@goneall @licquia Yes. If we don't plan to build docs for 3.0 again, I think it make sense to move over changes in this PR (publish_v3.yml and mkdocs.yml) to the PR #934, targeting 3.0.1.
@goneall Updated. Bring in changes for 3.0.1 by @licquia from PR #934 to here.
Thanks @bact - @licquia and/or @zvr - if you could do a quick review, we can merge
I'm not sure if we like to merge this at this time, since it has the tag latest and if the workflow starts it will publish the unfinished v3.0.1 - which I don't think we like it like that.
Normally, latest should point to the latest stable release, which is currently v3.0.
See more thoughts on this in next comment.
I'm try to rethink and find what more logical is:
- on every branches, set
canonical_versiontolatestmkdocs.yml:- mike: canonical_version: latest
- on
development/v3.0branch, setcheckoutto use3.0tag of modelpublish_v3.yml:- uses: actions/[email protected] # v3 with: repository: spdx/spdx-3-model ref: 3.0 path: spdx-3-model
- on
development/v3.0branch, setlatestalias to point tov3.0versionpublish_v3.yml:run: mike deploy -u -b gh-pages -p v3.0 latest
- on
development/v3.0branch, run the publish workflow to have the proper latest on the current stable release (v3.0)- The reason that we may need to run the publish workflow of v3.0 again is to fix things like PRs 928, 943, 950, 958, 959 (clearly not a change in content; only web navigation structure or typos; so they are not v3.0.1)
- on
development/v3.0.1branch, set the version (for mkdocs) tov3.0.1-draft(orv3.0.1-RCxxx) (an alias can be added, if needed)publish_v3.yml:run: mike deploy -u -b gh-pages -p v3.0.1-draft- The CI will checkout from
mainbranch (development branch) - The CI will publish the unfinished v3.01 to
v3.0.1-draftversion (selectable from dropdown list in HTML)
- (once v3.0.1 is ready) on
spdx-3-modelrepo, release it using the tag3.0.1 - (once v3.0.1 is ready) on
development/v3.0.1branch, setcheckoutto use3.0.1tagpublish_v3.yml:- uses: actions/[email protected] # v3 with: repository: spdx/spdx-3-model ref: 3.0.1 path: spdx-3-model
- (once v3.0.1 is ready) on
development/v3.0.1branch, publish it with3.0.1version, with the aliaslatestpublish_v3.yml:run: mike deploy -u -b gh-pages -p v3.0.1 latest
- (once v3.0.1 is ready) on
development/v3.0.1branch, run the publish workflow to have the proper latest on the current stable release (nowv3.0.1)
If this is correct and agreed:
- I should close this PR to and open a new pull request with content in (1)-(3) in
development/v3.0branch. That new PR will be reviewed and merged before (4). - PR #934 can be modified to be (5) and merge now, with the target of using it during the development period of v3.0.1
- Once v3.0.1 is ready, another PR with the content from (6)-(8) should be open and merge before (9)
--
Note: The content of (2)-(3) is PR #950 before the merge with #934 (this PR at the commit d44e0a6) but it should be on development/v3.0 branch instead.
- Note: We also need to decide on how to update the copyright information at the footer of the page as well. #930
- It is in the
copyright:section ofmkdocs.yml
- It is in the
https://github.com/spdx/spdx-spec/blob/aac3e38b0b01b2ccb129367617a07598cf0ccdd8/mkdocs.yml#L2
With this change, we will be advertising 3.0.1 as the latest; if we want to change that, we can do that with a slight change and some manual runs of mike. But I think we should go forward with this at least as a first step.
@licquia Also, this workflow need to be slightly adjusted once #978 and #979 are implemented - but I agree that we can take this PR as a first step and then having new PRs for new features.
Discussed in 2024-07-16 Tech team meeting - ready to merge.
The deployment was failed because v2.3 still occupied "latest" alias. Need to use -u option in mike deploy to override that.
- To assign alias
latesttov3.0, use this PR #994 - To publish v3.0.1 (development) as
v3.0.1-draft, use this PR #995