Publish last commit information

[RobPasMue]

Resolves #282

[RobPasMue]

@jorgepiloto @mkundu1 I came up with a less intrusive and more elegant solution (which does not imply committing anything on the fly).

I created a new Makefile target called "last-commit-info" which basically appends to the README.rst file a brief summary of the last commit of the branch in question. Then, when the install-post target is called and the packages generated, the PKG-INFO file contains the README.rst in its "long description" field.

Thus, now the information of the last commit is available whenever the package is generated in CI (for any branch). Please, see below an example of the modifications this new target does

[RobPasMue]

Find below an image of the PKG-INFO file generated consequently

[jorgepiloto]

I'm not sure if it possible to access PKG-INFO from the Python REPL. What about the following?

• Create a global variable named LAST_COMMIT in ansys/fluent/core/__init__.py.
• Use the following command in the CI to update its value to the latest commit metadata and hash.

git --no-pager log -n 1 --format='%an <%ae> - %ad - %h' | xargs -I hash sed -i "s/LAST_COMMIT.*/LAST_COMMIT = \"hash\"/g" ansys/fluent/core/__init__.py

Then, developers and users can run:

import ansys.fluent.core as pyfluent
print(pyfluent.LAST_COMMIT)

[RobPasMue]

I'm not sure if it possible to access PKG-INFO from the Python REPL. What about the following?

• Create a global variable named LAST_COMMIT in ansys/fluent/core/__init__.py.
• Use the following command in the CI to update its value to the latest commit metadata and hash.

git --no-pager log -n 1 --format='%an <%ae> - %ad - %h' | xargs -I hash sed -i "s/LAST_COMMIT.*/LAST_COMMIT = \"hash\"/g" ansys/fluent/core/__init__.py

Then, developers and users can run:

import ansys.fluent.core as pyfluent
print(pyfluent.LAST_COMMIT)

Fine by me as well. Looks quite nice in fact =)

[mkundu1]

Looks nice, thanks

[dnwillia-work]

import ansys.fluent.core as pyfluent
print(pyfluent.LAST_COMMIT)

OK, so if we are going there why not:

import ansys.fluent.core.as pyfluent
print(pyfluent.version_info())

and it prints something like

Build date: April 11, 2022 8:34 UTC ShaID: <id>

I think you can use date -u to get the first bit and substitute it using sed

[RobPasMue]

import ansys.fluent.core as pyfluent
print(pyfluent.LAST_COMMIT)

OK, so if we are going there why not:

import ansys.fluent.core.as pyfluent
print(pyfluent.version_info())

and it prints something like

Build date: April 11, 2022 8:34 UTC ShaID: <id>

I think you can use date -u to get the first bit and substitute it using sed

Fine, I'll include this modification as well =) I'll keep the variable though, and let the method return the string. Though I'll force the variable to be private now (i.e. "__LAST_COMMIT").

[dnwillia-work]

Fine, I'll include this modification as well =) I'll keep the variable though, and let the method return the string. Though I'll force the variable to be private now (i.e. "__LAST_COMMIT").

Yes, makes sense it can be private. Since it's not just the 'last commit' you might call it _VERSION_INFO. We usually use single underscore for this.

[jorgepiloto]

My only concern is if changes applied during the CI are commited to the actual repository. I think some kind of token needs to be used to effectively apply these changes to the codebase.

[RobPasMue]

My only concern is if changes applied during the CI are commited to the actual repository. I think some kind of token needs to be used to effectively apply these changes to the codebase.

Changes are not commited. They are included as part of the package generation, let's say. Thus it is not needed to push anything, and consequently, no need of token is necessary.

[jorgepiloto]

My only concern is if changes applied during the CI are commited to the actual repository. I think some kind of token needs to be used to effectively apply these changes to the codebase.

Changes are not commited. They are included as part of the package generation, let's say. Thus it is not needed to push anything, and consequently, no need of token is necessary.

You are right! This is only included when building the package as discussed in private.

[jorgepiloto]

LGTM 🚀