see adobe/helix-pipeline#78

In order for any pipelines other than HTML to work, HelixServer should not presume extensions:

There should be some sort of registry for available pipelines, or we could just iterate through available services in .hlx/build (thanks to @kptdobe for his support!)

@kptdobe commented on Jul 10, 2018, 12:41 PM UTC:

If there is an error during the rendering (like in a pre.js file), petridish just outputs:

[hlx] error: Error while delivering resource: TypeError: Cannot read property 'body' of undefined
    at Promise.resolve.then.then.then (/Users/alex/work/dev/playground/project-helix/modules/helix-cli/node_modules/@adobe/petridish/src/HelixServer.js:77:41)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:182:7)

which does not give an hint. It should return a proper 500 and at least log the exception.

This issue was moved by kptdobe from adobe/project-helix#256.

should it ?

there are a couple of vulnerabilities in transitive dependencies (e.g. hoek, cryptiles via git-server and nodesi) that need to be fixed.

Fastly and OpenWhisk generate both request and invocation IDs. We should do the same, so that adobe/helix-pipeline#61 can use the request ID instead of the time stamp to tag context dumps. In addition, #17 can then look up dumps from the current request and show them.

see https://github.com/adobe/project-helix/issues/278

@kptdobe commented on Oct 5, 2018, 8:57 AM UTC:

Description
Request to / (root) does not redirect to /index.html

To Reproduce
Steps to reproduce the behavior:

1. hlx up
2. Open http://localhost:3000/
3. See error:

[hlx] error: Error while delivering resource / - Error: resource at https://raw.github.com/adobe/project-helix.io/master/ does not exist. got 400 from server
    at Object.fetch (../project-helix/modules/petridish/src/utils.js:59:13)
    at <anonymous>

Expected behavior
Requests to / should be redirected to /index.html then to /README.html if no index.
The behavior should be the same than in production: URL must stay http://localhost:3000/ but render index.html (or README.html if no index).

Version:
run: $ hlx --version
0.7.13-pre.8

This issue was moved by kptdobe from adobe/helix-cli#245.

On a working project, just turn off the wifi and run hlx up: nothing is rendered.
Error message:

[hlx] error: Could not fetch Markdown from http://raw.localtest.me:60761/helix/content/master/index.md

Reason: the DNS name cannot be resolved. Using http://127.0.0.1:60761/raw/helix/content/master/index.md works.

cc @stefan-guggisberg @tripodsan

Let's make sure the error messages shown in the browser during development are really good.

I'd like to see:

• request dump (all headers and cookies)
• full stack trace
• code preview for all project code (resolve source maps, too)
• log messages from current request

Edit: something like Whoops would be ideal.

Request parameters passed via query string are currently ignored in HelixServer.

The core of HelixServer.js is a flow of Promises. The code could be rewritten using await / async calls instead in order to make it more readable.

This is a follow issue based on @tripodsan comment (#95)

Static files are served from the wrong repository. see adobe/helix-cli#188

adobe/helix-shared#3 adds logging to helix-shared which should be used in petridish

the server passes this._logger which is not the one in ctx.

In a fresh project, just add the action parameter to the pre function and output action.request.params.ref.

Code could look like this:

function pre(payload, action) {
  payload.content.time = `${new Date()}`;
  console.log(action.request.params.ref);
}
module.exports.pre = pre;

Run hlx up
Verify that the output is master.

Checkout a new branch: git checkout -b test
Run hlx up

-> the output is still master while it should be test.

While this is not an issue for default / simple use of the dev environment, this is an issue when starting to use the owner / repo / ref params to request extra stuff like in the nav case of helix-helpx: the code computes an git API call with those params and expect to be in the same "branch".

Nothing fails, just different content from another branch!

I lost quite some time today before realising my code was correct but the api result was the one from the master branch and not my current working branch!

For now only REPO_RAW_ROOT is provided. See https://github.com/adobe/petridish/blob/master/src/HelixServer.js#L42

[hlx] error: Unknown ref, cannot fetch content

because contentRepo is specified w/o ref. should fallback to configured default branch, which is mostly master

suggest to use a less funny name for this package and repository.

suggest

• helix-server
• helix-dev
• helix-sim
• helix-simulator

The local git-server should be started using a random port which then is used by petridish to confgure REPO_RAW_ROOT.

It should be possible for parameters be passed from hlx to petridish – e.g. the build directory is hard coded in petri, but a cli option in hlx

related to #64

petridish, i.e. specifically GitUrl and HelixProject don't support specifying a ref (branch) in a git url/strain config.

what's the canonical way of specifying a branch in a git url (strain config)?

the HelixProject class is not available as proper API export.

add:

index.js

module.exports = {
   HelixProject,
}

• use debug levels
• pass logger config to git-server

best would be to consider the manifest.json if to deliver a static file or not.
otherwise, for now just check if file exists below ./dist/

@kptdobe commented on Aug 16, 2018, 1:09 PM UTC:

Step to reproduce:

1. run hlx init test
2. edit src/html.pre.js and add console.log(payload.request); to the pre function
3. run hlx up
4. open http://localhost:3000/index.html
5. check the logs:

   { headers: undefined,
     params: 
      { owner: 'helix',
        repo: 'content',
        ref: 'master',
        path: 'index.md' },
     method: undefined }

headers and method are undefined but also missing the request details like uri, server...

This issue was moved by trieloff from adobe/hypermedia-pipeline#32.

Is there any specific reason why dump_html.js, the source file for local/.hlx/build/dump_html.js is not in the src folder ? Or are we supposed to edit the generated file directly ?

cc @tripodsan

helix-simulator should use the same set of libraries than the openwhisk container where the action runs.

suggestion:

• improve the custom docker container package with an action executor
• in helix-simulator, execute the compiled scripts via that executor instead directly in server.

the git-server dependency is set to "^0.9.7" which includes [email protected].
but since a newer git-server 0.9.10 is released, which includes [email protected] downstream dependencies will use the later git-server.

in circleci, the newer nodegit leads to problems, but it is not possible to revert back to the old version of helix-simulator.

$ npm ls nodegit
@adobe/[email protected] /Users/tripod/codez/helix/project-helix/modules/helix-cli
└─┬ @adobe/[email protected]
  └─┬ @adobe/[email protected]
    └── [email protected]

--> after addinh nodegit as hard dependency to helix-cli:

$ npm ls nodegit
@adobe/[email protected] /Users/tripod/codez/helix/project-helix/modules/helix-cli
└─┬ @adobe/[email protected]
  └── [email protected]

Suggest

• either use fixed reference for the git-server dependency here,
• or, git-server should use semver and increase at least the minor version when using a potential breaking change of nodegit.

Request http://localhost:3000/index.html?debug=true
-> debug=true does not appear in the payload nor in the secrets

Here is a config I am using:

staticRoot: /webroot
directoryIndex: index.html

strains:
    launch-docs:
        url: http://localhost:3000/docs/launch
        content: https://github.com/Adobe-Marketing-Cloud/reactor-user-docs.git#master
        directoryIndex: README.html

When I run hlx up, the "root" URL of the site loads fine. However, trying to load the sub-path http://localhost:3000/docs/launch yields a 404. In the above config, this path is mounted using the url directive or property or whatever it is called, and points to some external repo.

The logs from this 404 request look like this from hlx up output:

[hlx] debug: resolved /docs/launch/README.html -> html
[hlx] silly: before
[hlx] debug: Constructing HTML Pipeline
[hlx] debug: Creating pipeline
[hlx] debug: Running HTML pipeline
[hlx] silly: processing
[hlx] debug: Coercing secrets
[hlx] debug: fetching Markdown from http://127.0.0.1:57503/raw/helix/content/master/docs/launch/README.md
[git] debug: [rawHandler] resource not found: file not found: docs/launch/README.md
[hlx] error: Could not fetch Markdown from http://127.0.0.1:57503/raw/helix/content/master/docs/launch/README.md

It seems like local helix is trying to find the markdown from the mounted repo in the "current" or local repo.

I am happy to try to fix this, but I am still wrapping my head understanding how all of this is pieced together.

Another thought: would be nice to not map the url property to hostnames, but just to paths. Maybe I'm doing this wrong... probably I'm doing this wrong...

In line with adobe/helix-cli#79 we need a way to pass in a logger to HelixServer, etc. The existing logger should remain as a default fallback.

In order to support strains in petridish, it would be best to have a unified helix-config that can be used by both packages.

also see

• adobe/helix-cli#43
• https://github.com/adobe/project-helix/issues/271

The dependency snyk was updated from 1.110.2 to 1.111.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

snyk is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

see adobe/helix-cli#32

The petridish server should call the action the exact same way as the openwhisk controller.

#101 introduced a regression:

[hlx] error: resource at http://127.0.0.1:42686/raw/helix/content/master/welcome.txt does not exist. Error: options.uri is a required argument

• Run hlx init
• Create a folder and a md file in the folder (like test/index.md)
• In pre.js, output payload.path
• Request http://localhost:3000/test/index.html

The ouput shows test/index.html which is not really a path. Also, it is different from "production" where the output would be /test/index.html

the hypermedia-pipeline is a runtime dependency of the test scripts and should not be a direct dependency of petridish

When there are special characters like . in the query string, helix simulator will include them in parsing the selector and extension, which leads to files that cannot be found. The problem manifested itself in a scenario where a client token got passed back from an OAuth API.

Static resources (css, client side js...) are not rendered anymore. The temporary trick is not working anymore. See https://github.com/adobe/petridish/blob/master/src/HelixServer.js#L106-L115

providing an empty helix-config.yaml produces error:

Error: Unable to start helix: Cannot read property 'contentRepo' of null
    at _project.init.then.catch (/Users/tripod/codez/helix/project-helix/modules/helix-cli/src/up.cmd.js:118:15)

the code in src/config is used in helix-cli and petridish. as it should not be part of petridish, I suggest to move it to it's own repo.

suggest

• helix-config
• helix-shared

see #12

it should be configurable, if requests to / render the README.md or index.md.

default should be index.md

The .hlx folders are persisted in the various tests of the project. There is certainly a good reason for that but there is a major flaw: every time we change the helix-cli, the wrapper or the HTL Runtime we need to re-generate the .hlx to adjust the tests. Otherwise the tests keeps testing with old code. Not sure if there is something in place to automatically update but considering #48, I do not see how this could be automated.
We should at least document how to update the test (i.e. re-generate the .hlx folders in all test cases). That would still require some manual work.
Ideal solution: generate the folders on the fly when the test runs... (i.e. run hlx up before running the tests).

cc @tripodsan