Hi Karen, On Tue, May 4, 2021 at 5:13 PM Karen Lease <[email protected]> wrote: > I've made the changes as discussed below and pushed them to my forked > repositories for camel & camel-website (https://github.com/klease/camel > & https://github.com/klease/camel-website/). The changes from the main > repo are also merged & pushed to my fork; not sure that was necessary or > not.
This looks good to me, I've added a comment on GitHub to a commit in your fork about pointing the mailing list archives to lists.apache.org, i.e. for the users mailing list to point to https://lists.apache.org/[email protected]. Also, we don't need to point to Nabble any more, there was a spam concern (discussed on private@ in June of 2017) where we decided not to point folk to Nabble any more. > Running "yarn preview" and viewing the generated site locally looks > good, as well as the link check. Perfect, one thing that you might have missed is that to speed up the development some build steps and checks are disabled by default, to get a full build and all the checks you can set the environment variable `CAMEL_ENV=production`, there is a blurb on this in the README[1]. You can do this if you want a near production build, though all of this is run when a pull request is created so it's not obligatory. > > Before creating the pull requests I have a few more questions. > > 1. There is no contributing.md file in the camel-website/community > content but there is both a CONTRIBUTING.md file at the root of the > camel repository as well as the file > docs/user-manual/modules/ROOT/pages/contributing.adoc. All the > contributing links in the website reference the HTML file generated from > the .adoc file. The camel/README.md file references CONTRIBUTING.md. > These files are similar but not identical and both have been modified > recently. Would it make sense to also move the contributing.md file to > the community content & reference that one from everywhere, including > the main README? I think that makes sense, I'd keep the CONTRIBUTING.md file at the root of repositories and just point to the website from there. The reason behind having a CONTRIBUTING.md is that it became a sort of convention for open source projects on GitHub, to a degree where it's now part of the of the UI on GitHub[2] > 2. The camel/REAMDE.md has links to mailing-list and support pages which > are just http://camel.apache.org/support.html but end up on the > generated HTML pages in the user-manual so they'll be broken. I assume > it needs to be changed to https://camel.apache.org/community/support/? Yes, I think we need to be consistent here and have one URL to point folk to. > 3. When running "yarn preview" I hit the limit of unauthenticated API > requests on github to get the issues when building the release notes. > This gives errors like this "ERROR 2021/05/04 15:34:06 Failed to get > JSON resource > "https://api.github.com/repos/apache/camel-k-runtime/issues?state=closed&milestone=10": > Failed to retrieve remote file: Forbidden". Waiting a while and trying > again allows it to finish. There doesn't seem to be any way to > authenticate on the getJSON request in the Hugo template. It might be > worth mentioning it in the doc about building the website locally :) Yes, this is a known limitation, GitHub removed support for providing authentication tokens via URL parameters and the HTTP calls from Hugo can't include HTTP headers[4]. We get around that with caches, i.e. for Hugo `HUGO_CACHEDIR` can be set to a filesystem path that stores the caches. On ASF Jenkins we keep the cache, and for the checks running on GitHub I think we get higher API limits (or so it seems). And yes, it's definitely worth mentioning that in the README, I was hoping that custom headers in HTTP calls would land soon in Hugo so I didn't invest time in an alternative to getJSON. I think a pragmatic course of action would be to wait for this to get supported in Hugo until we see issues in publishing the website. Looking forward to the pull request :) zoran [1] https://github.com/apache/camel-website/#camel_env-environment-variable [2] https://github.blog/2012-09-17-contributing-guidelines/ [3] https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters [4] https://github.com/gohugoio/hugo/issues/5617 -- Zoran Regvart
