You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Certainly. Allow me to explain the situation first, and then we can determine the best location for this document.
The build_pkg.yml file serves as a reusable workflow that other packages can utilize. When modifications are made to the build_pkg.yml workflow, it often requires corresponding changes in the build_* scripts to handle the input variables or something else. Consequently, the git branch in build-package project should include changes to both the build_pkg.yml and build_* scripts together.
Without bind-mounting the build_* scripts inside the container, we would be unable to effectively test the build_pkg.yml workflow if the corresponding changes to the build_* scripts in the same branch are not present inside the container.
In addition to the specific utilize of the build_pkg.yml workflow from a particular branch using @workflow-branch-name, as demonstrated in this example: https://github.com/gardenlinux/package-htop/actions/runs/6823007358/workflow
There is an additional aspect to consider. When the actions/checkout action is used with repository: but without the ref:, it checkouts the default branch of the repository. Therefore, it is necessary to explicitly specify the ref: option with the workflow-branch-name that specific utilize from other packages along with the repository, as shown below:
This explains the presence of the ref: ${{ github.ref_name }} line in the previous version of this PR. I believe it won't harm to the workflow to cause any issues if the workflow is utilized by other packages in the default branch, as the variable will also be changed to the default branch.
(However, it's a workaround for testing purposes. I dropped it due to it's unrelated to the goal of this PR. Please let me know if we do need it or just to be needed in this document.)
Now, let's discuss the most appropriate placement and title for this document. :)
Here is the draft one from previous discussions:
Certainly. Allow me to explain the situation first, and then we can determine the best location for this document.
The
build_pkg.yml
file serves as areusable workflow
thatother packages
can utilize. When modifications are made to thebuild_pkg.yml
workflow, it often requires corresponding changes in thebuild_*
scripts to handle the input variables or something else. Consequently, thegit branch
inbuild-package
project should include changes to both thebuild_pkg.yml
andbuild_*
scripts together.Without bind-mounting the
build_*
scripts inside the container, we would be unable to effectively test thebuild_pkg.yml
workflow if the corresponding changes to thebuild_*
scripts in the same branch are not present inside the container.In addition to the specific utilize of the
build_pkg.yml
workflow from a particular branch using@workflow-branch-name
, as demonstrated in this example: https://github.com/gardenlinux/package-htop/actions/runs/6823007358/workflowThere is an additional aspect to consider. When the
actions/checkout
action is used withrepository:
but without theref:
, it checkouts thedefault branch
of the repository. Therefore, it is necessary to explicitly specify theref:
option with theworkflow-branch-name
that specific utilize from other packages along with therepository
, as shown below:This explains the presence of the
ref: ${{ github.ref_name }}
line in the previous version of this PR. I believe it won't harm to the workflow to cause any issues if the workflow is utilized by other packages in thedefault branch
, as the variable will also be changed to thedefault branch
.(However, it's a workaround for testing purposes. I dropped it due to it's unrelated to the goal of this PR. Please let me know if we do need it or just to be needed in this document.)
Now, let's discuss the most appropriate placement and title for this document. :)
Originally posted by @alee-ntap in gardenlinux/package-build#8 (comment)
The text was updated successfully, but these errors were encountered: