I know that a git push origin master will let Openshift redeploy the application to its new version.
But my situation is that my Tomcat application depends on another sub-module maven project, and they are both snapshot.
Once its sub-module project changes (the Tomcat application remains the same), the git push origin master doesn't work at all (Everything up-to-date) and of course Openshift will not redeploy my application, which means that it doesn't renew the newest sub-module snapshot artifact for me.
So, how to solve this problem? I have tried rhc restart and rhc reload, but they doesn't work. Is there some command like rhc redeploy?
You can run
rhc app deploy HEAD -a <appname>
if you're using the command line tools
You can start the deploy steps by ssh'ing to your openshift application. Check your ssh line from https://openshift.redhat.com/app/console/applications/ -> Click your application and then "Want to log in to your application?". Check https://www.openshift.com/developers/remote-access for detailed help (thanks RustyTheBoyRobot).
Once in, run:
gear deploy
Are you sure that you've pulled and committed the most recent changes to the submodule? What's probably happening is the reference to the desired submodule commit isn't updated, so even though the submodule has changed, you project doesn't really know about it. I believe git submodule status should show you the commit your main project currently knows about.
To update this reference, follow these directions.
[main]$ cd ./subm
[subm]$ git pull origin/master # or fetch then merge
[subm]$ cd ..
[main]$ git commit ./subm -m "Updated submodule reference"
If you actually committed changes in the last step, then OpenShift should update it appropriately (since this time, there were changes to the git repo).
Related
I have an app on Heroku. According to the Heroku App deploy guide I followed the below steps to modify the master.
Steps to make the push on Heroku
$ git add .
$ git commit -am "make it better"
$ git push Heroku master
The build of deploy was successful but the changes didn't reflect on the browser. I used hard refresh multiple times but didn't work.
If your app requires a build step to compress and combine assets and you are not seeing recent changes, then it's likely that you are forgetting to run that build step.
If you are using package such as parcel-bundler. you should run it before you deploy it. That would solve the issue.
You can read more on how to run it automatically whenever you deploy your app from here.
https://devcenter.heroku.com/articles/node-best-practices#hook-things-up
I want to set an opensource project where users can be sure that the deployed version .heroku.com corresponds with the actual source code in github master branch github.com/
Is there any way to prove a heroku deployment corresponds to a github repo?
Your app can spit out the latest deployed Git SHA if it has the "Dyno Metadata" feature turned on: https://devcenter.heroku.com/articles/dyno-metadata
Using that, you can show the latest SHA and compare it against the public repo.
Also, to add to what Jon said, you can do this via the heroku releases command. Every release, be it a code deployment, config var is 'tagged' - the command will show you everything that has changed on your app and a deploy will show the short git SHA, you can copy the SHA and then use the git command to search the repo for it.
eg.
assuming heroku releases returns
v10 Deploy 33f21247 foo#bah.com 2018/09/03 10:01:38 +0100
then you could do:
git cat-file commit 33f21247
which will then output the corresponding match, or a message saying it's not found. Obviously, this assumes your local repo is in sync with GitHub. To check it against GitHub you'd need to open your repo on GitHub like:
https://github.com/heroku/{projectname}/commit/{sha}
which will show the same commit on GitHub.
I'm using Golang and GitLab CI, and I've got a GitLab CI configuration which works perfectly for 12 projects, but not for a 13th.
The problem I have is that I'm trying to go get some private repositories, which go get tries to run over HTTPS, which is turned off.
The solution, that works in the other repos, is this:
git config --global url."git#gitlab.my.site:".insteadOf "https://gitlab.my.site/"
However, in the runner for this one project, on the same GitLab, with the exact same config (except for the service name), this happens:
[...]
$ git config --global url."git#gitlab.my.site:".insteadOf "https://gitlab.my.site/"
$ cd ${APP_PATH}
$ go get
# cd .; git clone https://gitlab.my.site/group/project.git /go/src/gitlab.my.site/group/project
Cloning into '/go/src/gitlab.my.site/group/projects'...
GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.
Why is it suddenly trying to clone over HTTPS? It happens in this one project only, consistently, but works in all the other ones. The only reason I can think about is that this one project uses a lot of different repos, rather than just one or two, but I have a hard time seing that this would be the actual issue.
How can I troubleshoot this?
Thanks.
Found the answer, and it's silly, and of course, my fault. I hadn't added the deploy key to the projects, of course rejecting the clones.
To fix the problem, in GitLab, go to the repository and then "Settings" > "Repository" and fold out "Deploy keys". There, make sure that the key you're trying to clone with is available and enabled.
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events
I am trying to implement automated builds using Jenkins for my iOS projects. I added the Git plugin, but as soon as I try to put the URL for git in the git configuration for the project, it is showing the error in the screen shot below. Here Jenkins cannot clone from the repo to its workspace.
For the "Repository URL" field it is expecting a remote repository URL, something like git#github.com:github/hubot.git. It will use that url to copy down code to run the job against.
If you just want to run a job in a particular directory where you already have the code you want to work against, then leave this section empty. You can set the directory that you want to run a job in by
1. scroll to the "Advanced Project Options" section
2. click "Advanced"
3. Check "Use custom workspace"
For one off things, this is fine, but if you use this a lot, I think you'll find it more useful to commit your code to github and have jenkins clone down a fresh copy of code for each run.
You will get that error if you miss the following cases:
Whenever the clone URL is wrong.
When you are trying to clone from a place where you don't have the
access to git server.
Whenever your Pem key is not added to the list of keys on the git
server.
In most cases git bare repo has extension .git
I mean (other)/test1 dont look correct, i think it should be (other)/test1.git had this same error on my mac.
Actually i solved the issue . it was because of the permission the remote git is not updating properly