| commit | fc7e272421b9d95d304f1578c3c38993d6924bc2 | [log] [tgz] |
|---|---|---|
| author | Steve Lawrence <slawrence@apache.org> | Wed Dec 21 17:02:24 2022 -0500 |
| committer | Steve Lawrence <slawrence@apache.org> | Thu Dec 22 07:28:01 2022 -0500 |
| tree | 215412b79d76a47c8bf141fee4d5f2fe2de5a94a | |
| parent | 28bb46f5289241eb71dca6f30f0b782d010e6119 [diff] |
Update release artifact and checksum URLs The closer.lua page does not provide any information we don't already provide. The mirrors that it used to list have been replaced by a CDN link, and we already provide a message and link describing how to verify downloads on our download page. This has also been known to cause issues when users try to wget/curl a download link, since they just download an HTML page instead of the actual intended artifact, causing confusing about failed installations or invalid gpg signatures or checksums. To avoid this issues, we still use the closer.lua link but now append ?action=download to the URL path, which causes closer.lua to automatically download the file instead of showing an HTML page. One drawback is that wget will include the query parameter in the downloaded file name, but infra is considering some solutions to this. Additionally, closer.lua is aware of archived artifacts, so we can use the same URL for archived and non-archived URLs. The downloads.apache.org URL is also aware of archived .sha512 and .asc release artifacts, so these too can use the same URL for all releases. By using these URLs, we no longer need to update previous release pages when they are archived. We just need to delete old releases from dist.apache.org and download links will automatically redirect to the archives, removing one manual step from the release process. And because all these download URLs never change depending on archive, this now hardcodes them into the site logic instead of having to duplicate them in every release version page. This also hardcodes the KEYS file URL and removes it from each version page, since that also never changes.
The Apache Daffodil website is based off of the Apache Website Template.
The website is generated using Jekyll and some plug-ins for it.
To improve reproducibility and to minimize the effects and variability of a users environment, it is recommended that changes to the site repo be tested locally with a container. To do so, run one of the following commands.
With docker:
docker run -it --rm \ --publish 127.0.0.1:4000:4000 \ --volume="$PWD:/srv/jekyll" \ docker.io/jekyll/jekyll:4.2.0 \ jekyll serve --watch --source site
With rootless podman:
podman run -it --rm \ --publish 127.0.0.1:4000:4000 \ --volume="$PWD:/srv/jekyll" \ --env JEKYLL_ROOTLESS=1 \ docker.io/jekyll/jekyll:4.2.0 \ jekyll serve --watch --source site
Then open http://localhost:4000 to view the site served by the Jekyll container. Changes to files in the site directory are automatically rebuilt and served.
Once satisfied, create a branch and open a pull request using the Daffodil project Code Conttributor Workflow but using the website repo instead of the code repo.
Daffodil uses gitpubsub for publishing to the website. The static content served via Apache must be served in the content directory on the asf-site orphan branch. When changes are merged into the main branch on GitHub, a GitHub action will automatically run and perform the necessary steps to publish the site.