in my workflow I tag git commits before updating master which is then automatically build with netlify. I’m using git describe to get the current version to show up in my app.
However it looks like Netlify doesn’t fetch tags when building. This means the output of git describe is something like 1.0.3-14-3hj34b2(14 commits after the last tag it found). It works if I clear the build cache and rebuild.
Is there a way to get Netlify to also fetch new tags during build?
Hey @Markus,
We currently have an open feature request for this internally, but as far as I can tell, it is not currently implemented. I will update this if I learn otherwise.
One hacky thing you might try is seeing if you can experiment with different git commands’ exit codes here to get us to not ignore the build:
We also recently rolled out Build Plugins, which have a git utility that may be able to do some checking before build, i.e., in onPreBuild:
Let us know if we can help further with any of that.
Hi @Markus did you figure this out? We’re seeing the same issue. The commit history is there but the tags are missing on the recent commits. If I clear the cache and rebuild, the tags are there.
git clone project
cd project
git submodule update -f --init
When we build FROM cache, we start with the last copy of your repo (what was cloned; not what might have been created in that directory during build!) and then we do this:
Thanks for sharing the commands. After debugging locally I think adding a git fetch should do the trick. Will give it a go.
Don’t suppose you could update your command to
git fetch -f -u ---prune-tags --tag remote ref
I don’t think this would be a breaking change and means the tags are synchronised with the remote. Not sure if there would be much of a performance hit.
The permissions that the build image uses to access the repo are immediately dropped by the build image after the initial repository clone or fetch. This means you will need to configure additional permissions to access the repo if you want to work with it after the initial clone or fetch.
Hypothetically, the instructions for accessing other repositories can be extended to access the initial repository after the build images drops the default permissions. Those instructions can be found here:
Using those instructions you should be able to work with the repo after the clone or fetch. If there are questions about configuring this access, please let us know.
So, could you explain in more detail how you have things configured? That workflow should still work well but you didn’t share many details about what you actually did. I’m hoping for something like:
added deploy key’s private SSH key to the repo as path/to/key
then I ran some git operation (I do not believe that git remote -v actually does this - I think it just shows the local config in .git!) that talks with my git provider, using a verbose flag, and saw this output around permissions:
quoted output
You can see this output in my build linked logs at this link
Armed with those details, we should be best able to help!
I was hoping that alone would mean that the keys weren’t cleared after the initial clone.
With your instructions it sounds like we should make the private key available in the environment and the configure it with git. This exposes the private key to deploys running from forks which isn’t ideal, although if it only has read only access maybe it’s ok. I will give this a go.
Would it not be possible for you to fetch the tags at the same time you fetch the commit before you drop the permissions? I think changing your command to
git fetch -f -u ---prune-tags --tag remote ref
would do it. Or if you can’t do this for performance reasons I think it would be better if you didn’t fetch any of the tags, because right now it’s inconsistent based on when someone does a deploy after clearing the cache.
Changes like the one you describe are of course possible but very nontrivial here: they will apply to ALL of our >1 million of our customers and basically we cannot change anything at that level without extensive testing and it is a huge lift on our side to help the dozen or so people who have expressed a need to use tags like this. We do have an open feature request to do so and this thread will be notified if it happens!
But for today we’ll want to find you a workaround.
Deploy Keys aren’t mentioned in that article around your use case, though. They are only mentioned around OUR clone before build starts - not any command you would run during build.
You’ll have to use one of the methods in the LAST 3 bullet points in that article, rather than the first three, to allow YOU to run git commands with the permissions you supply. The deploy key is to grant our pre-build system access to your submodules, and those permissions are dropped (for your safety - nobody breaking into your build container has permissions to read or modify your repo from github!) before build.