Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Job間のartifactは引き継がれない #15

Open
waviaei opened this issue Aug 7, 2023 · 3 comments
Open

Job間のartifactは引き継がれない #15

waviaei opened this issue Aug 7, 2023 · 3 comments

Comments

@waviaei
Copy link
Member

waviaei commented Aug 7, 2023

現象

Job の build と deploy がある場合、build でビルドしたアウトプットは deploy には引き継がれない。needs: ['build'] してもダメ。

actions/checkout#19 (comment)

Each job runs in a fresh version of the virtual environment, so you'd need to checkout for each job. You can have multiple steps for each job, and the environment will remain across steps, but you aren't able to persist the environment entirely across separate jobs.

If you need to persist data across different jobs you may want have a look at using the artifact upload and download actions. This will allow you to pass files/folders between different jobs:

https://github.com/actions/upload-artifact
https://github.com/actions/download-artifact

なので、workflow は完走するが、ビルドされたファイルがデプロイされずに、checkout し直されたビルド前のファイル群がデプロイされた。
確認されたのはこの yml で、
https://github.com/tarosky/ls-kitaharahosp-theme/blob/chore/issue%2392/.github/workflows/deploy-to-production.yml
走ったこのactionです
https://github.com/tarosky/ls-kitaharahosp-theme/actions/runs/5764676781

解決案

案1
上記にもあるように upload-artifact と download-artifact を使う。しかしこれでは tarosky/workflows/.github/workflows/npm.yml@main に upload-artifact を付け足す必要があり、その artifact をどうにか別の workflow に渡すということが必要。

案2
「ビルド」部分を workflow ではなく、composite action にしておいた方が step として組み込めるので、複数の job がある step の中にも、単体で1つの job でも、状況によって組み込みやすい?
ただし、with に相当するものを渡せるようにしないと使い勝手は悪くなる。

@waviaei
Copy link
Member Author

waviaei commented Aug 7, 2023

@fumikito
https://github.com/tarosky/gutenberg-fust/blob/master/.github/workflows/wordpress.yml
を参考に👆を実装したのですが、書いた通り、完走してますが実はビルドされる前の状態のものがデプロイされていました。 fust の workflow でも同じことが起きてないか気になりました。

@fumikito
Copy link
Contributor

fumikito commented Aug 7, 2023

@waviaei

fustでは、ここでビルドしてます。
https://github.com/tarosky/gutenberg-fust/blob/master/.github/workflows/wordpress.yml#L63-L70

「ビルドしてzipに固める」というのはよくあるフローなので、それだけ切り出せると良いかもです。
また、ビルドスクリプトにしているのは、 10upのorgにデプロイするアクションみたいに、「一個だけスクリプト実行できる」というケースが多いからです。

ビルドスクリプトはこちらですが、これも毎回似たようなものをリポジトリにコピーしているので、共通化したいですね。

https://github.com/tarosky/gutenberg-fust/blob/master/bin/build.sh

@waviaei
Copy link
Member Author

waviaei commented Aug 7, 2023

@fumikito
共通化はしたいですね。

受託系のものは今全て deploy with rsync していますが、少なくともプロダクションへのデプロイは一般的なテーマと同様に zip 化してからアップロード、もしくは rsync した後で zip 版も作っておく、ということをやっておいた方が良いかもしれません。
とはいえ、ステージング(や開発)で毎回zip化のが良いのかも微妙なところで。

うーn。

composite action の方もそれはそれで確認してみます。

ひとまず件のテーマでは workflow においたファイルを使わないで実行して解消はしています。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants