Best way to create a development environment (identify & then document)

[LukasWallrich]

@DAKiersz @bethaniley I would need your ideas here.

@flavioazevedo is looking for a way to work with @ThomasRhysEvans on a new resource - for which we'd need a development environment.

My thinking was the following:

• clone the repo (due to constraints on Actions in forks)
• simplify the deploy action to create a GitHub page of the development version
• add a 'noindex' so that the development page does not confuse search engines.

I tried that here but weirdly, the GitHub page does not show any formatting at all. I can try to debug that - but before spending any more time on that, I was wondering whether you think this is even the right direction - or whether you have a better idea.

Once we have figured out the best solution for this situation, we should document that for future projects.

[DAKiersz]

Hi Lukas,

Is there anything required by this project that cannot be build and tested locally (with either a devcontainer running Hugo or a local install of Hugo server) prior issuing a PR from a folk, that can then be reviewed and tested on our end? In other words, is there need for a dedicated dev/staging environment for this?

There is nothing wrong with using GH pages to publish the fork under a different domain, and a dev or a ephemeral staging environment is often preferable to a local server when it is required (e.g., do you need to use a remote dev database, do you need dedicated cloud resources that cannot be reliably recreated locally etc..). However, first step is always the accessibility of local development, and that is why I am asking this first.

It might be easier to get on a call next Friday to discuss this - tagging @bethaniley to this as well.

[LukasWallrich]

Fair point, thanks - local dev on a branch / draft PR may be enough. I thought it would be easier for collaboration among less experienced folk to have access to a shared live version of their work - but the way to get there is probably for me to work on the development environment for PRs rather than a whole separate setting.

So, for that, would you be happy with a setting similar to the staging where PRs get deployed on request into dedicated folders? To deal with space, I think the action should first delete closed PRs and then the oldest deployment if needed.

Then people can collaborate on a branch, develop locally, but also refer to a shared online version for status checks etc.

[LukasWallrich]

@DAKiersz for now I created a draft PR for this (#158) - let's see how this works for collaboration, and then maybe use it as the case study to document :)

[github-actions[bot]]

This issue has been inactive for more than 90 days. If there is no further activity, it will be automatically closed in seven days time. You can reopen the issue if it is still relevant.

[github-actions[bot]]

This issue has been automatically closed due to it being stale for more than 7 days. Please feel free to reopen if you still want this issue.