Closed sernaferna closed 1 year ago
@sernaferna Hi, I had a similar problem, which I recently solved, so I thought I'd reply. The problem is, if you bump a package version using bump-version, does that mean you won't get the latest commit the next time check out? Try once more after provide a ref to the checkout used by the build-app1 job.
build-app1:
needs: [paths-filter, bump-versions]
if: ${{ needs.paths-filter.outputs.aapone == 'true' }}
steps:
- uses: actions/checkout@v3
- with:
ref : ${{github.ref}} # <-- add this line
- name: Build container
- name: Push to registry
- name: Deploy to k8s
this github context give workflow a full reference of branch. If you haven't solve already, give it a try. Hope this helps
@SpookyJelly gave the solution that solved the problem! Adding the github.ref
worked like a charm! (And is probably what I should have been doing in the first place, but I've resolved not to feel dumb about it...)
Minor correction from the code snippet above that the with
shouldn't have a dash in front of it, it's part of the uses
step, but that's just a typo.
This is going to be a long one because of the code snippet, so... apologies.
I've got a build and deploy script for a monorepo that does the following:
dorny/paths-filter
to find which projects in the monorepo have changedgh-action-bump-version
to increment the version of any project that has changed (with skip tag)gh-action-bump-version
again to increment the version (and the tag) for the entire monorepoEverything in this process works except that the build mentioned in step 4 never gets the updated version numbers from steps 2 & 3. When I pull the latest version of the code from GitHub it's all there, but step 4 in the process doesn't seem to get that version of the code. The code deployed to my cloud environment is always one step behind the version numbers in GitHub.
I'm not sure if this is a
gh-action-bump-version
issue or if I'm just doing something wrong from a GitHub Actions perspective; I have a feeling it will be the latter and this will get close as not an issue. 🙂 It's as if everything gets committed, but not until after the deployment job has finished.Here's what my YAML looks like (with a lot of detail elided), but the job involving
gh-action-bump-version
is pretty much as-is in case I'm doing something wrong in calling that action: