-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
fetch-tags is not working according to the docs with v4 #1781
Comments
I'm getting this too. I don't want to set fetch depth to 0. e: Looks like this still breaks if I use |
We should not be required to add this, but fetch-tags: true seems broken. See actions/checkout#1781 for a second opinion, and possible resolution.
We should not be required to add this, but fetch-tags: true seems broken. See actions/checkout#1781 for a second opinion, and possible resolution.
We should not be required to add this, but fetch-tags: true seems broken. See actions/checkout#1781 for a second opinion, and possible resolution.
checkout@v4 fetch-tags: true does not seem to work as expected [1]. Version matrix ends up missing the tag for stable: matrix={"include":[{"ref":"master","name":"dev"},{"ref":"","name":"stable"}]} Work around this by reverting back to running git fetch --tags manually. [1] actions/checkout#1781
Still an issue. |
The issue looks like this for us: We are running 4.1.7 and use
We use |
Also not working for me. I have
EDIT: You can see that they are not adding |
You need to create a fork of the repo first and then make a PR towards the original repo. |
I'm experiencing something related, wherein I am using |
* Upgrade deps * Upgrade to Go 1.23; support Go 1.20+ * Require Go 1.22+, upgrade deps * CI: Debug git describe --tags * Is there a bug in actions/checkout@v4? actions/checkout#1781 * Fix go.sum * Improve inferring webrpc-gen version from a Go module
**What does this PR do?** This PR is a second attempt at adding 3.4-asan builds (first attempt was ruby#13); this version is now atop ruby#14 . It introduces a new "3.4-asan" build, based on the existing asan builds, but just pointed at the `ruby_3_4` branch. In ruby#13, we were building the latest tagged 3.4 release, which I expect would be more stable than just using `ruby_3_4` (and thus better for my downstream purposes of "having a build that doesn't fail for non-asan-related reasons"). Switching between both options is as simple as: ```diff diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 7eb72a8..d7608d9 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -29,6 +29,8 @@ jobs: with: repository: ruby/ruby path: ruby + fetch-tags: true + fetch-depth: 0 # Workaround for actions/checkout#1781 - name: Set latest_commit id: latest_commit working-directory: ruby @@ -37,7 +39,8 @@ jobs: id: latest_commit_3_4_asan working-directory: ruby run: | - git checkout ruby_3_4 + LATEST_TAG=$(git tag --list | grep -E "v3_4_[0-9]+$" | sort -V | tail -n1) + git checkout "$LATEST_TAG" echo "commit=$(git rev-parse HEAD)" >> $GITHUB_OUTPUT - name: Check if latest commit already built uses: actions/github-script@v7 ``` I personally prefer building from the tag, but happy to use the branch option if that's preferrable. **Motivation:** The intention of "3.4-stable" is to provide the latest up-to-date stable Ruby, so that we can reliably use it as a breaking CI step. As discussed in ruby/setup-ruby#682, the current ruby-asan builds are a bit of a "sharp edge" when used in CI because they may break due to changes that are completely unrelated to asan. Building asan rubies is a bit awkward still, as e.g. ruby-build and other version managers don't have support for it, and it requires very modern versions of specific system tools (e.g. clang). **Additional Notes:** In particular, I decided to not touch the logic that determines weather there's a more recent commit to build or not. This does mean that if ruby master sees no commits, but there's changes in the 3.4 branch, this won't be picked up immediately; and it also means that if there's a new master commit and no change to the 3.4 branch we still rebuild 3.4-asan. My thinking is that given that ruby#14 added caching already, this approach keeps things simple. Let me know if you're not convinced, and I can change that. **How to test the change?** I've built this in the downstream fork, and manually downloaded the resulting Ruby and it seems to be in good shape and with asan working fine. * Successful run: FIXME * Resulting builds: FIXME
Hello, hope you're good. I'm running some experiments in order to build a custom action that demands the tags from the repo. I noticed that it was possible, in theory, just using the
fetch-tags: true
, but it does not work. I can only get the tags if I use thefetch-depth: 0
.Example workflow:
The last command (
git tag --sort -creatordate
) shows nothing in this case.But, if I use the
fetch-depth: 0
, it lists correctly the tags from the repository.The text was updated successfully, but these errors were encountered: