Highlighted
Trusted Contributor.
Trusted Contributor.
96 views

Build Artefact Diet Plan?

We're experimenting with Docker and deploying in images build artefacts created from Visual COBOL 5.0 for Eclipse for Windows.  We're using Git/Bitbucket for source code management and Nexus Pro to store build artefacts.  We use Bamboo for build and deploy.  I noticed some build outputs that we are including in Docker and storing in Nexus and wonder if they truly need to be deployed.  I would appreciate reading your opinions regarding the following file types:

  • .lst file - who looks at listing these days?
  • .obj -  if we always produce dlls/exes in our build,  do we need to deploy obj files?
  • .idy - nice to have, but with 2000+ COBOL programs, an expensive luxury? If we have all the branch source stored safely in Git, is it better to create debug files on demand as needed? 
  • obj.1.tlog - what is a tlog file and why do I care? 

Thanks!

Labels (4)
0 Likes
1 Reply
Micro Focus Expert
Micro Focus Expert

Hi @StompinBob 

lst files: Personally I wouldn't have thought you would need these on a  Docker image.

obj files: you would only need these if the Docker image ever needs to rebuild executables so probably not.

idy files: If you ever need to debug code running on the Docker image you would need these. 

tlog files. These are used by the build system to track dependencies so unless the image ever builds a project they would not be required.

I hope that helps. 

Gael

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.