Can I modify my openshift git repo using ssh shell? - openshift

I have working app on OpenShift server. My question is - how to update openshift's git repo of my application, if I make some changes using ssh acsess to openshift? I mean not using all this stuff with pull/push to my local mashine.

If I understand you correctly, you would like to modify source code without using git. I am not sure why you would want that. All that stuff with pull/push gives you a version control flexibility which can save you a lot of time when you screw up one thing. For example, you push brand new UI to production, which turns out to be buggy. With git, you have flexibility to revert back to previous version, and work on different branch to fix the bug on UI.
OpenShift follows conventional app structure. Git for source control, maven for build, jbosseap(for example) for app server, jenkins for continuous integration, etc. So, when you push using git, OpenShift will automatically build using maven, then deploy to the server.
If you would like to disregard all that advantages that OpenShift has to offer, use rhc ssh appname to directly work on the server.

Related

Redeploy Openshift Application when Docker Hub Image Changes?

Is there a way to trigger a re-deploy when I push an image to docker hub? I used S2I to build an image, put it up on docker hub, and did a deployment from there. How can I trigger a new deployment when I push a new image to docker hub?
Perhaps there is a better way? I created a wildfly image with the changes to the standalone.xml I needed. Then I used S2I to build my local source into a runnable wildfly application image, which is what I pushed and deployed. I'm trying to get around having to go through a github repository.
I'm thinking I could create an application with the customer wildfly image that I created and use the direct from IDE option to the application, but what if I want to use the command line?
You can set a scheduled flag on the image stream to have a remote registry periodically polled. This will only work though if the OpenShift cluster has been configured globally to allow that. If using OpenShift Online I don't believe that feature is enabled.
https://docs.openshift.com/container-platform/latest/dev_guide/managing_images.html#importing-tag-and-image-metadata
If you want to avoid using a Git repository, you can use a binary input build instead. This allows you to push files direct from your local computer. This means you can compile binary artifacts locally and push them into the S2I build done by OpenShift.
https://docs.openshift.com/container-platform/latest/dev_guide/builds/build_inputs.html#binary-source

DIY Tomcat, where is the webapp folder on the local git repo

following OpenShift tutorials, creating a tomcat application and clone it, the local repository will contain a pom.xml, webapp folder.
What's the equivalent on a diy application that contain a diy and misc folders
Thank's in advance, any help is appreciated cause I'm really stuck here !?
Update
Well I've install a Tomcat 8 DIY application following this tutorial here everything works fine, I can see the Tomcat page in the browser, the problem is how to deploy a .war file.
For a Tomcat 6/7 application on OpenShift, the local git repository have this structure:
____Tomcat7/6
|_________ webapp
|_________ src
|_________ pom.xml
But for a Tomcat 8 DYI application I have this structure
________Tomcat8/diy
|__________ Diy
|__________ misc
|__________ readme
So Where to deploy my .war files, cause there is no webapp folder?
The title of your question suggests that you are mixing up at least 5 different, completely independent & orthogonal tools and concepts:
Git is a version control system ("push", "local repo")
Maven is a build tool ("pom.xml")
Apache Tomcat is a servlet container ("Tomcat 6/7/8")
rhc is some client tool provided by yet another cloud computing platform ("OpenShift")
Your code is the stuff that you have written, it's completely under your responsibility.
Before you start doing anything, please make sure that you have at least some basic understanding of what each of these tools does. Then ask yourself whether you really need Tomcat 8 instead of Tomcat 7, and whether a 2 year blog post about the compilation of Tomcat 8 within an OpenShift gear is the best source. All these deployment details can change pretty quickly, if it worked two years ago, it's not guaranteed that it would work now.
I've never worked with OpenShift, but as far as I understand, the basic idea is this:
You write your code
You create your OpenShift account and allocate some "Gear" (or "Dyno" or whatever...) for your application
You commit your source code (/src) and the files that are necessary for the build (pom.xml), and use git to push it to the repository OpenShift gave you.
OpenShift then uses your pom.xml and builds all the WAR-files on it's own
Then you can use your rhc client tool to start your application, if that's not done automatically.
Some of these steps can be changed.
If you really have to, you can indeed compile your own Tomcat8, the tutorial you linked tells you how (more or less. The dude who did it obviously knew what he was doing there, so he might have skipped some details that seemed trivial to him).
Furthermore, if you really want, you can deploy pre-packaged WAR-files, by deliberately removing all the stuff that is necessary to build you app (removing pom.xml and all the /src), and instead adding the packaged application to your git repo, and then pushing it all to OpenShift. Then it will skip the build step, and just run what you gave it. OpenShift seems to provide some information about this deployment strategy: https://help.openshift.com/hc/en-us/articles/202399740. Please read the documentation and make sure you understand what you want to do. For example, filter-branching your git repo and removing all source files you have ever written is not a good idea, even if you don't need these files on OpenShift.
Currently, I don't see anything of the standard tomcat directory structure in the tree that you show. Instead, there seem to be just some basic ruby-scripts or some other default-demo-app-stuff... That's why it's called "do it yourself". If you don't want this, take a standard Tomcat7 app.

How to implement continuous deployment with Nexus and Jenkins

I'm trying to implement a continuous deployment system and I seem to not be able to find a good answer for our problem.
We use Jenkins to run a maven build to generate our artifacts and deploy them to Nexus. I see a few projects that bundle up everything into a single war or tar file, extract one file per request from Nexus by name and deploy it to an application server, but this requires them to know beforehand what versions they have available.
My project has quite a few jars/wars/binaries among other artifacts, which don't get deployed using an application server. What we want to do is be able to do is pull any snapshot or release revision of the software out of nexus and either generate an install package or deliver it directly to a remote server.
Clarification: I want QA or development to be able to select a version from Jenkins; where Jenkins will poll Nexus for the available versions, then perform an automated deploy to a server from Nexus.
Is there an easy nexus/maven way to get software out to a testing system?
So, is there a way to poll nexus to determine what revisions are available through ant/ivy, Jenkins, maven, gradle? I'll write in something else if it helps.
I see that a similar question was asked here: How do I choose an artifact from Nexus in a Hudson / Jenkins job?, but it is as of yet unanswered 9 months later.
Nexus gives you a standard HTTP browsing capability. You could browse the repository through HTTP and see what is available.
I still don't understand your Use Case though. If you know which versions of the project you want then what is the problem?
The easiest would be to write an installer pom.xml that has in it a ${} placeholder for the version you want for the artifacts then invoke mvn with mvn package -Dproduct.version=1.0.0
If you use a container, PAX has plugins that allow you to specific artifacts like mvn:myGroup/myArtifact/myVersion and it will auto pull from Maven.
Nexus isn't doing any magic. It's all well known paths on a URL of groups/artifactId/versions

How do I choose an artifact from Nexus in a Hudson / Jenkins job?

I have a job in Hudson server A which builds an artifact and deploys it to Nexus. I have another job in a completely separate Hudson server B which needs to download the artifact and deploy it. This job is normally run manually, and the person running it needs to indicate which version of the artifact to deploy - they may not always want to deploy the latest version (e.g. to roll back to a previous known good version).
Currently, I achieve this by using a parameterized build, and require the user to pass in the artifact version number; the job then uses the Execute shell build step to run wget on a URL constructed using the parameter. This is error prone.
Ideally I'd like a plugin that lets the user browse the artifact versions in the Nexus repository and pick and choose the one to deploy, but I'm open to other suggestions. A plugin that also handles the download would be nice, but I can live without it as long as I can still get a string that I can use in shell commands.
I've looked through the available Hudson & Jenkins plugins around Maven style artifact repositories, but they all seem more concerned with pushing artifacts into repos rather than getting them back down.
I'm using Hudson's "Copy Artifact" in other jobs, to get artifacts from other Hudson jobs on the same server, but this doesn't work across different Hudson servers, which is why I've turned to Nexus (which we're already using anyway).
Does anyone have any suggestions?
I recommend using rundeck to execute your deployments.
There is a rundeck plugin for Nexus that enables rundeck to display a pull down menu of available versions in Nexus.
There is a rundeck plugin for Jenkins that can be used to invoke deployments using rundeck and kick-off post deployment jobs (like integration testing) inn Jenkins.

Configuring Bazaar in Hudson

I am trying to configure a task in Hudson for a VC++ project. I was able to build a project from the file system with MSBuild task. But when I try to configure the task to check out a bazaar repo to do the build, checkout is always failing in authentication. Bazaar passwordless access is setup on the machine and when I use bzr cmd line, checkout is happening without password. Another post suggested that I should have the id_rsa in C:\Documents and Settings\Administrator.hudson - but that also did not help. In Subversion config I saw a way of mentioning username and password. Is there any way to get around this problem.
I assume you have set up the authentication in the windows equivalent of ~/.bazaar/authentication.conf (use bzr version -v to get the correct location).
Is hudson running as the same user as the one you use to connect with the command-line? Because that will impact which authentication.conf it will try to use.
My hudson is using authentication.conf fine but I run it on Ubuntu.
I solved the problem. The authentication.conf is not being considered in windows. I made the repo accessible through http and configured the bazaar with that URL. It was able to download the repo with http protocol without asking for password. One more thing I did was I created a username in hudson, which I matched with a user having access in the bazaar repo which solved another problem which was asking for a user named pwd.