How do I inject password via CI CD?

[tangara goh]

I have "seen" my supervisor using CI CD to inject passwords rather than hardcode in Java classess but I have no chance to learn from him cos he already made up his mind to ditch me for good and I am left with less than 3 months to get a job...and I still can't do the algorithm test within 5 mins....

So, I am hoping someone can tell me how to do it.

I tried to learn Docker but I still have yet to come across a tutorial like that.

Or should I look at Kubernete ?

I am really L..O..S..T...so really appreciate some helps here.

Tks.

[Stephan van Hulst]

I don't know what you mean by "using CI CD to inject passwords".

Do you mean how to get a password from environment specific configuration? Usually continuous deployment systems allow you to set environment variables for the system that the application will deploy to. You could configure the path to a configuration file where the password is located (or even configure the password itself) and then read it from the Java application.

How to do it exactly depends on the CI/CD system you're using.

[tangara goh]

Stephan van Hulst wrote:

Do you mean how to get a password from environment specific configuration? Usually continuous deployment systems allow you to set environment variables for the system that the application will deploy to. You could configure the path to a configuration file where the password is located (or even configure the password itself) and then read it from the Java application.

How to do it exactly depends on the CI/CD system you're using.

Yes.  My apologies I am abit fuzzy about this cos I have only like thought about this and then I was just told using CI/CD but I had no idea how it is done.

Also, today, I discovred about this which is something that I have seen another supervisor had done it but I really don't know where to pick up this skill.

https://www.eclipse.org/justj/

The build-jre.sh script is used by a Jenkins pipeline script which in turn is used by the build-jres job to produce the following downloads:

where can I start at beginner level to learn how to do build-jre.sh ?

[Stephan van Hulst]

Uhh for what? Why do you want to build a JRE?

[tangara goh]

Stephan van Hulst wrote:Uhh for what? Why do you want to build a JRE?

Sorry Stephan, let me rephrase my question.

I just want to take a small step to learn this shell script to build thing or automate stuff.

Can you let me know how do I start ?

Tks.

[Stephan van Hulst]

No. Your question basically amounts to: "Can you tell me how to use a hammer to become a master violin player?"

I'm sure it can be done, but step 1 is: "Put the hammer away and tell me what you consider to be a master violin player, and maybe settle for a simpler goal first".

What thing do you want to build? What do you want to automate that you now have to do manually?

[Tim Holloway]

tangara goh wrote:I just want to take a small step to learn this shell script to build thing or automate stuff.

While it's hard to tell  for certain, it sounds like you're referring to a script developed in-house by your current employer for their own internal use. Once that employer has dumped you out on the streets, you'll likely never see that script again. So there's no point in trying to learn anything about it.

In the wider world, most Java apps are built using Maven, Ant or Gradle. Probably the most useful one to know at the moment is Maven, although that depends on what your next employer may prefer.

Beyond that, I don't know what CI CD means either, and Docker/containers are very different to build tools.

Oh. Come to think of it, I guess you mean Continuous Integration/Continous Deployment. That's a very broad topic and application building is only a very small part of it. Do try and avoid unexplained acronyms, though. IBM has at least one acronym I know of that has at least 4 different meanings and uses, depending on which of their products you're referring to and you probably wouldn't be able to guess any of them. And that's just in the IBM world.

[tangara goh]

Tim Holloway wrote:

tangara goh wrote:I just want to take a small step to learn this shell script to build thing or automate stuff.

While it's hard to tell  for certain, it sounds like you're referring to a script developed in-house by your current employer for their own internal use. Once that employer has dumped you out on the streets, you'll likely never see that script again. So there's no point in trying to learn anything about it.

In the wider world, most Java apps are built using Maven, Ant or Gradle. Probably the most useful one to know at the moment is Maven, although that depends on what your next employer may prefer.

Beyond that, I don't know what CI CD means either, and Docker/containers are very different to build tools.

Oh. Come to think of it, I guess you mean Continuous Integration/Continous Deployment. That's a very broad topic and application building is only a very small part of it. Do try and avoid unexplained acronyms, though. IBM has at least one acronym I know of that has at least 4 different meanings and uses, depending on which of their products you're referring to and you probably wouldn't be able to guess any of them. And that's just in the IBM world.

Sorry about it...I thought CI CD is something that a developer would know ...I will avoid that.
I guess I have to prepare for the worse...and anyway my coding skill is really bad...even now I really think I am not cut out for it.....

Could you share with me abit more where do I pick up shell scripting meant for Continous Integration/Continous Deployment ?

[Tim Moores]

While it's possible to use shell scripts for CI/CD (as your company apparently does), it's also unusual. Tim H mentioned the tools that are commonly used; shell scripts are so unusual in this context that it's hard to advise what to learn, besides shell scripting in general.

[Tim Holloway]

For Continous Integration there are tools like Jenkins, Travis, TeamCity, Bamboo and more. My only real experience is with Jenkins, but it's a web application that can monitor source control and other resources and manually or automatically run builders such as Maven or Gradle. It can also monitor CI testing (Maven, for example, can run jUnit tests and build reports) and thus provide a dashboard for the statuses of many projects. It can build dependent projects and it can deploy the results of builds. It's a multi-user system with a variety of security features so that, for example, junior programmers cannot accidentally (or deliberately) dump an unscheduled build into production.

Jenkins is a JEE webapp, commonly run under jetty or Tomcat. Or, in my case, run under Tomcat in a Docker container. It can be deployed very rapidly that way. It's not scripted, although you can implement custom plugins as JavaBeans, Plugins are available for all sorts of things including CD/provisioning systems like Ansible and Puppet and various source code versioning and control systems. To use Jenkins, you just log in and start filling out web forms to define your projects and their inter-relations (if any).

All of the CI platforms I've mentioned above have been posted as requirements for employment at different shops. Jenkins is especially popular because it's available for free, but big installations often prefer one of the commercial products so they will have someone they've paid to yell at.

If you're proficient with Docker, that's probably the fastest way to get Jenkins running, but there are many other options, including OS installer packages for the Red Hat/CentOS platform, Debian/Ubuntu and Windows. Or if you're brave, you can download Jenkins as a WAR and deploy it yourself, although you'll have to set up some infrastructure for things like work directories.

But even more important than knowing something like Jenkins is knowing build systems like Maven. Because Jenkins expects to outsource the actual job of building apps to products like Maven.


If your lack of confidence is based on criticism of your ability to handle some one-off weird Do-It-Yourself system of your current employer, as I said, don't expect to ever see it again. Such systems are usually poorly designed, poorly documented and typically if you need help you have to ask someone who doesn't want to help you. Which is one reason why standard CI/CD systems are so popular. If no one will help, there are vendor forums, books, and... the Build Tools forums on the JavaRanch!

[Dave Tolls]

And since Tim has mentioned Jenkins, and to bring it back to the immediate question of the thread, Jenkins has a secure password store which you can use to pass password parameters to, eg, your integration tests.
I expect all the others do to. At least the ones (whose names I can never remember) have the same sort of thing.

Edit: and a link if anyone's interested:
https://www.jenkins.io/doc/book/using/using-credentials/

[Tim Holloway]

On the deployment side, products like Ansible often have their own secure mechanisms, such as Ansible Vault.