paulononato/backstage
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity

fix: prettier formatting

Browse Source 
Signed-off-by: Eric Swanson <ericis@users.noreply.github.com>
This commit is contained in:
Eric Swanson
2021-03-29 18:59:38 -04:00
parent 858d1edcd3
commit aaa3dd2c53
2 changed files with 17 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
contrib/make/README.md
+6 -6
View File
@@ -14,15 +14,15 @@ Containers, like [Docker](https://www.docker.com/), enable an immutable definiti
## Issues and considerations
* Hosted and sometimes proprietary tasks may be unavoidable, like those offered in the GitHub Actions marketplace or tasks built into products like the core capabilities of Jenkins or through plug-ins. These tasks typically require a "poke the server" approach to debugging end-to-end workflows or containerizing the installation and configuration of the products themselves to be executed as larger containerized tasks. This might introduce the need for guidance on when to define containerized tasks and when to lean on hosted and/or proprietary solutions.
* Cross-platform presents challenges. Getting consistency across Linux, macOS, and Windows requires knowledge and effort. A quick argument can be to standardize on Linux shell across these three major platforms, but even working across Linux distributions presents some unique challenges too.
* Consider the balance of developers freedom of choice in tooling with the consistency with standardized tooling that can be achieved with containerized execution environments. Empower developers to "opt-out" and swap tooling choices wherever possible to experiment and innovate.
- Hosted and sometimes proprietary tasks may be unavoidable, like those offered in the GitHub Actions marketplace or tasks built into products like the core capabilities of Jenkins or through plug-ins. These tasks typically require a "poke the server" approach to debugging end-to-end workflows or containerizing the installation and configuration of the products themselves to be executed as larger containerized tasks. This might introduce the need for guidance on when to define containerized tasks and when to lean on hosted and/or proprietary solutions.
- Cross-platform presents challenges. Getting consistency across Linux, macOS, and Windows requires knowledge and effort. A quick argument can be to standardize on Linux shell across these three major platforms, but even working across Linux distributions presents some unique challenges too.
- Consider the balance of developers freedom of choice in tooling with the consistency with standardized tooling that can be achieved with containerized execution environments. Empower developers to "opt-out" and swap tooling choices wherever possible to experiment and innovate.
## When to use this pattern
* To ensure task execution consistency across a variety of environments, especially across developer workstations and remote DevOps servers
* For tasks that are particularly fragile and/or complex (e.g. developers consistently reporting setup and environmental issues)
* Code editors and "Integrated Development Environments" may offer support for containerized development, like Visual Studio Code's Remote Development extension. This pattern can easily be extended to support these scenarios. One important consideration is GUI tooling support. Most task execution shouldn't require a GUI, especially for remote DevOps tasks. However, developers might use GUI tooling that could also use containerization or virtualization. So, consider how to achieve both. For example "Docker in Docker" (DiD) could enable a GUI development container to execute containerized tasks in separate containers.
- To ensure task execution consistency across a variety of environments, especially across developer workstations and remote DevOps servers
- For tasks that are particularly fragile and/or complex (e.g. developers consistently reporting setup and environmental issues)
- Code editors and "Integrated Development Environments" may offer support for containerized development, like Visual Studio Code's Remote Development extension. This pattern can easily be extended to support these scenarios. One important consideration is GUI tooling support. Most task execution shouldn't require a GUI, especially for remote DevOps tasks. However, developers might use GUI tooling that could also use containerization or virtualization. So, consider how to achieve both. For example "Docker in Docker" (DiD) could enable a GUI development container to execute containerized tasks in separate containers.
## Example
contrib/make/makefile
+11
View File
@@ -82,6 +82,17 @@ check-docs: install
.PHONY: lint-docs
lint-docs: check-docs
.PHONY: check-prettier
check-prettier: install
@docker run --rm -it \
--name $(docker_name_timestamp_prefix)-$@ \
--network host \
-v $(project_root_dir_path):/app \
-w /app \
--entrypoint "" \
$(docker_tag) \
yarn run prettier:check
# BUG: the frontend seems to run on "$(backend_port)" (7000 default).
# The documentation states "This is going to start two things,
# the frontend (:3000) and the backend (:7000)."