There are several steps missing from the golang Templ documentation when installing the command line tools on Mac.
The following are the walk-through steps you'll want to take so you can run templ generate from the mac command line
| <!-- | |
| Since the markup IS the application state, using data-* attributes to keep track of some specifics would be handy. | |
| Luckily, HTMX is brutally easy to extend, so we can do that in no time! | |
| --> | |
| <article class="message task" | |
| th:id="'task'+${task.id}" | |
| th:data-task="${task.id}" | |
| th:data-status="${task.status.id}" | |
| th:hx-put="@{/task/{id}(id=${task.id})}" | |
| hx-ext="hx-dataset-include" |
There are several steps missing from the golang Templ documentation when installing the command line tools on Mac.
The following are the walk-through steps you'll want to take so you can run templ generate from the mac command line
์คํ๋ง ๋ถํธ์์๋ ์ ํ๋ฆฌ์ผ์ด์
์์ ํ์ํ ์์ฑ์ "์ ํ๋ฆฌ์ผ์ด์
๊ตฌ์ฑํ์ผ" application.yml(ํน์ applicatoin.properties) ์ ์์ฑํ์ฌ ํ์ฉํฉ๋๋ค.
|
Note
|
๋ฐ์ดํฐ๊ตฌ์กฐ๋ฅผ ๊ณ์ธตํ์ผ๋ก ํํํ ์ ์์ด์ ๊ฐ์ธ์ ์ผ๋ก |
๊ฐ๋ฐ ๋จ๊ณ์์ ํ์ด์ง ์ฒ๋ฆฌ ๋ฑ ์๋ ๋ฐ์ดํฐ๊ฐ ํ์ํ ๊ฒฝ์ฐ๊ฐ ๋๋ฌ ์๋ค. ์ด ๋ Flyway ์์ ์ ๊ณตํ๋ Repeatable migration ์ ํ์ฉํด ์๋ ๋ฐ์ดํฐ๋ฅผ ๊ด๋ฆฌํ๋ฉด ์ด๋ค ์ ์ด ํธํ ์ง ๊ทธ๋ฆฌ๊ณ ์ ์ํ ์ ์ ๋ฌด์์ด ์๋ ์ง ์์๋ณด์.
Repeatable migrations have a description and a checksum, but no version. Instead of being run just once, they are (re-)applied every time their checksum changes.
Repeatable migration ์ ๊ฐ์ฅ ํฐ ํน์ง์ checksum ๊ฐ (= ๋ณ๊ฒฝ ์ฌ๋ถ ์ฒดํฌํ๋ ๊ฐ) ์ด ๋ณ๊ฒฝ๋ ๊ฒฝ์ฐ ์ฌ๋ฌ ๋ฒ migration ์ด ์ ์ฉ๋๋ค๋ ์ ์ด๋ค. SQL-based migration ์์ Repeatable migration ์ ์ฌ์ฉํ๊ธฐ ์ํด์๋ R__{description}.sql ์ ๊ฐ์ ํ์ผ์ ์์ฑํ๋๋ฐ, ์ด๋ฏธ migration ์ฒ๋ฆฌ๋ ํ์ผ์ ์์ ํ๋ฉด checksum ๊ฐ์ด ๋ณ๊ฒฝ ๋๋ฉด์ ํด๋น ํ์ผ์ ๋ด์ฉ์ด ๋ค์ migration ์ฒ๋ฆฌ ๋์์ด ๋๋ค๋ ๊ฒ์ด๋ค.
์์ ๊ฐ์ ํน์ง์ผ๋ก ๋ณ๋์ ๋ฒ์ ์ ๋ณด๋ฅผ ๋ฐ๋ก ๊ด๋ฆฌํ์ง ์๋๋ค.
์๋ ๋ฐ์ดํฐ๋ฅผ ๊ด๋ฆฌํ ๋ Versioned migration ๋ณด๋ค Repeatable migration ์ ์ฌ์ฉํ๋ฉด ํธ๋ฆฌํ ์ด์ ๋ ์์์ ์ธ๊ธํ ํน์ง์์ ์ฐพ์ ์ ์๋ค. Versioned migration ์ ๋ฒ์ , ์ฆ ํน์ ์์ ์ ์ํ ์ ๋ณด๋ฅผ ๊ฐ์ง๊ณ ์๊ณ ๋ฐ๋ผ์ ๋ฑ ํ ๋ฒ๋ง migration ์ฒ๋ฆฌ๊ฐ ๋๋ค. ๋ฐ๋ผ์ ์๋ ๋ฐ์ดํฐ๋ฅผ Versioned migration ์ผ๋ก ๊ด๋ฆฌํ๋ฉด ์๋ ๋ฐ์ดํฐ์ ์ถ๊ฐ ๋ฐ ์ญ์ ์ ๊ณ์ ํด์ ํ์ผ์ ์์ฑํด์ ๋์ํด์ผ ํ๋ค.
| package gunlee.demo.fiber; | |
| import org.junit.jupiter.api.Test; | |
| import java.io.BufferedReader; | |
| import java.io.IOException; | |
| import java.io.InputStreamReader; | |
| import java.lang.management.ManagementFactory; | |
| import java.lang.management.ThreadInfo; | |
| import java.lang.management.ThreadMXBean; |
| <!DOCTYPE html> | |
| <html lang="en"> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <meta name="viewport" content="width=device-width, initial-scale=1.0"> | |
| <link href="https://unpkg.com/tailwindcss@^1.0/dist/tailwind.min.css" rel="stylesheet"> | |
| <script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></script> | |
| <script src="https://cdn.jsdelivr.net/npm/axios/dist/axios.min.js"></script> | |
| <title>Alpine and axios</title> | |
| </head> |
With GitHub Actions, a workflow can publish artifacts, typically logs or binaries. As of early 2020, the life time of an artifact is hard-coded to 90 days (this may change in the future). After 90 days, an artifact is automatically deleted. But, in the meantime, artifacts for a repository may accumulate and generate mega-bytes or even giga-bytes of data files.
It is unclear if there is a size limit for the total accumulated size of artifacts for a public repository. But GitHub cannot reasonably let multi-giga-bytes of artifacts data accumulate without doing anything. So, if your workflows regularly produce large artifacts (such as "nightly build" procedures for instance), it is wise to cleanup and delete older artifacts without waiting for the 90 days limit.
Using the Web page for the "Actions" of a repository, it is possible to browse old workflow runs and manually delete artifacts. But the procedure is slow and tedious. It is fine to delete one selected artifact. It is not for a regular cleanup. We need