CI: implement release/deployment changes - #455
Conversation
After the wording change preparing for the deprecation of scheduled releases, this patch implements the changes in CI workflows to deploy the webpages and to create releases with the PDFs on every commit. The three existing workflows (that build PDFs and the pages for correctness check, and the link check) continue to be executed for PR creation and updates (new commits). Three new workflows are added which run only on updates to the main branch (PR merges and direct pushes, if any). Those: - create a release with the PDF files in GitHub's release page, - build the webpages, and - deploy the webpages to the site.
rockdreamer
left a comment
rockdreamer
left a comment
There was a problem hiding this comment.
Could you try running this under act and make sure the parts other than the final publication complete? See https://nektosact.com/
Your version passed this linter https://rhysd.github.io/actionlint/ so that's good.
My comments are purely stylistic. If you can run with act, and you're confident about the ifs you added, LGTM. If you find something not quite right, I trust you'll make the right changes :)
| with: | ||
| name: pdfs | ||
| path: pdfs | ||
| path: | |
There was a problem hiding this comment.
In this case, we are individually renaming the files to add the commit hash, and workflow artifacts are apparently necessarily packages (not individual files)
| run: ./tools/build-github-pages.sh build | ||
|
|
||
| markdown-link-check: | ||
| if: github.event_name == 'pull_request' || (github.event_name == 'push' && github.ref == 'refs/heads/main') |
There was a problem hiding this comment.
Which cases does this filter out? Is it useful to filter them out?
There was a problem hiding this comment.
The ifs are there to select when each workflow is executed.
build-pdfs: checks PDF correctness in PRs and allows their publishing in releases by create-release
build-github-pages: only PRs, to check pages for correctness
markdown-link-check: PRs and merges, to check links
create-release: only merges, to publish releases
build-pages-artifact: only merges, builds the pages and prepares them for deployment
deploy-pages: only merges, deploys the pages
| name: Main build ${{ github.sha }} | ||
| target_commitish: ${{ github.sha }} | ||
| files: | | ||
| pdfs/acle-${{ steps.vars.outputs.short_sha }}.pdf |
There was a problem hiding this comment.
Same as the other comment, only that releases accept individual files
|
@rockdreamer act is very interesting, I did not know about that. But I am not able to execute any workflows because of docker-in-docker. |
rgwott
changed the title
|
Yeah, this might make some of the changes I made in the other PR clearer ;) |
|
Can this PR be split into individual ones?
Additionally, I think not would be beneficial to avoid overusing word release as we are no longer aiming to provide ACLE releases, maybe publishing/updating the document is a better wording for comments/CI jobs names. |
3 participants
NOTE: as is the nature of this change, the portion that implements post-merge actions cannot be tested before the PR is merged.
After the wording change preparing for the deprecation of scheduled releases, this patch implements the changes in CI workflows to deploy the webpages and to create releases with the PDFs on every commit.
The three existing workflows (that build PDFs and the pages for correctness check, and the link check) continue to be executed for PR creation and updates (new commits).
Three new workflows are added which run only on updates to the main branch (PR merges and direct pushes, if any). Those:
name: Pull request
about: Technical issues, document format problems, bugs in scripts or feature proposal.
Thank you for submitting a pull request!
If this PR is about a bugfix:
Please use the bugfix label and make sure to go through the checklist below.
If this PR is about a proposal:
We are looking forward to evaluate your proposal, and if possible to
make it part of the Arm C Language Extension (ACLE) specifications.
We would like to encourage you reading through the contribution
guidelines, in particular the section on submitting
a proposal.
Please use the proposal label.
As for any pull request, please make sure to go through the below
checklist.
Checklist: (mark with
Xthose which apply)PR (do not bother creating the issue if all you want to do is
fixing the bug yourself).
SPDX-FileCopyrightTextlines on topof any file I have edited. Format is
SPDX-FileCopyrightText: Copyright {year} {entity or name} <{contact informations}>(Please update existing copyright lines if applicable. You can
specify year ranges with hyphen , as in
2017-2019, and usecommas to separate gaps, as in
2018-2020, 2022).Copyrightsection of the sources of thespecification I have edited (this will show up in the text
rendered in the PDF and other output format supported). The
format is the same described in the previous item.
tricky to set up on non-*nix machines). The sequence can be
found in the contribution
guidelines. Don't
worry if you cannot run these scripts on your machine, your
patch will be automatically checked in the Actions of the pull
request.
introduced in this PR in section Changelog for year 20xx (this year)
of section Preface/About this document.
Create Changelog for year 20xx if it does not exist. Notice that
changes that are not modifying the content and rendering of the
specifications (both HTML and PDF) do not need to be listed.
correctness of the result in the PDF output (please refer to the
instructions on how to build the PDFs
locally).
in the README page of the project.