When we do a commit to git, is it possible to have git create a file that contains the git revision number?
We need to be able to get the git revision number from our production environment. However, in our production environment we do not have access to the .git directory, so we need another way of trying to be able to get the current revision of the code that is running on the server. We are using elastic beanstalk. They just basically allow our production environments to be booted up from our git repository, but it doesn't include any of the .git directories.
This isn't possible because the commit ID (the only thing Git has that is a revision ID of sorts, though there is also the somewhat easier-to-read output from git describe that requires tags to exist in your repo in the right places) depends on the contents of the commit. If you calculate the commit ID based on the current contents and then insert it, the contents change and so the commit ID is now different from the one you calculated.
In general the way to go is to generate the commit ID in another place, e.g. while making the code available to whatever uploads it to the production environments. The same thing is required in build processes and, in those, usually works like this:
- Get ID of current commit (e.g.
git rev-parse HEAD) and write it into a file. In C projects, this might be a header file. - Use that file within the build process, e.g. by
#include-ing it in a source file.
Similarly, for deployment of code, you might simply have the job that pushes the code create an extra file (that is pushed along with the rest) that contains the commit ID.
When we do a commit to git, is it possible to have git create a file that contains the git revision number?
We need to be able to get the git revision number from our production environment. However, in our production environment we do not have access to the .git directory, so we need another way of trying to be able to get the current revision of the code that is running on the server. We are using elastic beanstalk. They just basically allow our production environments to be booted up from our git repository, but it doesn't include any of the .git directories.
This isn't possible because the commit ID (the only thing Git has that is a revision ID of sorts, though there is also the somewhat easier-to-read output from git describe that requires tags to exist in your repo in the right places) depends on the contents of the commit. If you calculate the commit ID based on the current contents and then insert it, the contents change and so the commit ID is now different from the one you calculated.
In general the way to go is to generate the commit ID in another place, e.g. while making the code available to whatever uploads it to the production environments. The same thing is required in build processes and, in those, usually works like this:
- Get ID of current commit (e.g.
git rev-parse HEAD) and write it into a file. In C projects, this might be a header file. - Use that file within the build process, e.g. by
#include-ing it in a source file.
Similarly, for deployment of code, you might simply have the job that pushes the code create an extra file (that is pushed along with the rest) that contains the commit ID.
0 commentaires:
Enregistrer un commentaire