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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CI pipelines for model component repos currently cannot access the composite actions that are called in the reusable workflows for this repo. It seems that this is because GitHub actions defined in a called repo (e.g., sandialabs/firewheel) are executed as if they were defined in the caller repo (e.g., the MC repo).
An example of this failing behavior can be found in the recent CI pipeline for the firewheel_repo_dns repo. That repo cannot find .github/actions/prepare-tox because it's looking for it in the sandialabs/firewheel_repo_dns repository rather than sandialabs/firewheel where it actually lives.
I was hoping there might be a way to tell the caller repo to look for things in the called repo, but the closest related info I've found so far is an issue suggesting this might not be possible. There are many suggestions there, including those for choosing specific branches, but I think that it probably just makes the most sense for us to use the full path to the action (e.g., sandialabs/firewheel/.github/actions/prepare-tox) in our workflows until we need a more sophisticated system.
I quote the link to that issue here as a place to go looking if we eventually need a more complete strategy, such as a new repo only containing actions and similar to the CodeQL Action repo that is linked there.
Also, that danielchabr/pr-labels-check job seems to be unable to identify branches on forks. @sdelliot Do you know if there's a way to configure it to look at forked branches?
Also, that danielchabr/pr-labels-check job seems to be unable to identify branches on forks. @sdelliot Do you know if there's a way to configure it to look at forked branches?
I believe that this is because we are not using pull_request_target in the .github/workflows/release-drafter.yml (see https://github.com/sandialabs/firewheel/pull/65/files) but it seems hard to test this relies on using information from the primary repository so merging/testing seems to be the only way. Additionally, there are some known security concerns that we will want to evaluate prior to making that change.
ciChanges to our CI configuration files and scripts
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mitchnegus
force-pushed
the
reusable-ci
branch
from
CI pipelines for model component repos currently cannot access the composite actions that are called in the reusable workflows for this repo. It seems that this is because GitHub actions defined in a called repo (e.g.,
sandialabs/firewheel) are executed as if they were defined in the caller repo (e.g., the MC repo).An example of this failing behavior can be found in the recent CI pipeline for the
firewheel_repo_dnsrepo. That repo cannot find.github/actions/prepare-toxbecause it's looking for it in thesandialabs/firewheel_repo_dnsrepository rather thansandialabs/firewheelwhere it actually lives.I was hoping there might be a way to tell the caller repo to look for things in the called repo, but the closest related info I've found so far is an issue suggesting this might not be possible. There are many suggestions there, including those for choosing specific branches, but I think that it probably just makes the most sense for us to use the full path to the action (e.g.,
sandialabs/firewheel/.github/actions/prepare-tox) in our workflows until we need a more sophisticated system.I quote the link to that issue here as a place to go looking if we eventually need a more complete strategy, such as a new repo only containing actions and similar to the CodeQL Action repo that is linked there.