We are using Jenkins Freestyle Project to push the changes on the remote server. We are executing shell script on remote host using ssh for it. To pull the changes on remote host, we are using origin url with git username and git password. The credentials should not be visible in plain text in the url that’s why we have stored them in variables using ‘secret text(s) or file(s)’ option of ‘Build Environment’.
At the Jenkin’s end it is working as it is expected. The git credentials are not visible to the users who are using Jenkins for other projects but we are facing issue on the remote server where project was deployed. The remote server is showing git credentials in plain text. Any user with ssh access of the remote server is able to run the git reflog command in the project directory.
Port 22 cannot be opened on the server where gitlab is deployed so we cannot use ssh keys method to create the build in Jenkins. We can use only http method to pull the changes.
Is there any way so we could implement to avoid showing the git credentials in plain text in the project directory.
Go to Source
I am getting this “gradlew permission denied” error after pushing my code to my GitLab repository. The build is not able to continue because the gradle wrapper is not able to run.
What is causing this and how to fix it?
From a local terminal/command line, use the Git command that follows to fix this issue:
git update-index --chmod=+x gradlew
Continue to commit the modifications to the gradlew file.
Push the changes to your Git repository.
You can read more at this page: https://www.joseyamut.xyz/2020/08/15/fix-gradlew-permission-denied-on-openshift-deploy/
I am familiar with deploying a personal app to Heroku with
git push and scaling it up by adding more dynos. But how do you deploy to a scaled AWS infrastructure with thousands of private instances behind dozens of load balancers across multiple regions?
I have searched and searched for this on Google and only found “hello world” tutorials describing cloning a repo directly to a single instance, or using CodeDeploy to deploy to a single instance, and then using autoscaling groups. Basically equivalent to my Heroku example.
But what does it actually look like in production systems at say Facebook, GitHub, Twitter, Stripe, or other large companies, if they were to run on AWS? Are they pushing to a single “global” bastion instance, and then it fans out to the rest of the private instances across multiple regions in one swoop? Or is some sort of plan (like a terraform plan) created, which needs manual approval, and then there’s a custom deploy script which ssh’s into the bastion instance and then fans out to each region? Or is it a git hook integrated into CI somehow? Are AMIs typically produced? Is a Load Balancer switch switched? Etc.
What is typical of a large AWS deployment in terms of how you actually deploy your latest code changes to production, given you have thousands of instances across multiple availability zones and regions?
I am just wondering about a single service. I would imagine this process would be repeated per microservice or whatever. So for the sake of the question, imagine there is a single webserver with thousands of instances in every region. How would a deployment for that typically look? I am looking to create some GitHub actions to deploy to AWS as practice for a large project, but have no idea what the state of the art is, and haven’t been able to find any information on the topic.
These are sort of helpful:
Go to Source
Author: Lance Pollard
My git flow is similar to the github flow- ephemeral feature branches that merge to and from
master after code review and QA.
However there is one important difference- in order to QA, developers merge to
staging. In most cases this merging happens in the CI- merge conflicts are rare.
There are (atleast) 3 issues:
- In some cases, some PRs make it to
staging but not to
master (PRs get rejected). For now, developers deal with it by manually re-setting
master we do a “squash and merge” while in
staging its the standard merge. No specific issue because of this right now but seems like it might break in the future.
- Merge conflicts have to resolved twice- once when deploying to staging, and another time when merging to master.
Is there a way to achieve to have branches to have code deployed to
staging but not to
master and keep
master somewhat in sync without manual intervention.
One idea that comes to mind:
The CI keeps track of which branches are in staging (but not in master)- say all open PRs that a developer has marked “ready for staging”. On every staging deploy, the
staging branch is reset to
master and these branches are merged. But I’m not sure how a CI would save this kind of “state”. Not to mention, this seems like a very complex flow.
Go to Source
We work on multiple java web projects going on at the same time and those are all being tested on several different QA environments. Id like to show on our support portal what projects are in what environments without having to manually updated it all the time. I was thinking of some what to tag the build so I could just query tomcat or those linux servers themselves and show the results. The tags would be something like “August Release”, “Project 1”, “Project 2”, etc.. Has anyone done something similar? I’m looking for different options.
Go to Source
When using a centralized version control system such as SVN, where every commit acquires an auto-incremented number, it is relatively easy to track what version is released to production by simply setting the version to the identifier of the commit. Version 18.104.22.16822, for instance, matches the 18,522th commit.
With distributed version control systems such as Git, however, the identifiers are hashes, rather than numbers. I can hardly imagine someone on the phone saying: “There is a regression in our version 2F90C275A,” and non-numeric versions don’t play well with some tools, which means that versions are dissociated with the commits: commit 2F90C275A may become version 22.214.171.124, “15” here being the value of an auto-incremented counter in the build tool.
In practice, I find it particularly challenging to find which is the commit of a particular version, and I need to know the mapping to be able to answer a bunch of questions, such as:
- “Is [a given change] that was committed last Friday morning part of the version 126.96.36.199?”
- “What could have broken [a given feature] in version 188.8.131.52?”
- “Let’s do a hotfix. From which commit exactly should we create the hotfix branch?”
If one imagines that the build is done in a way that virtually any commit from the
origin/master can be pushed later on to production, how am I supposed to manage versions properly in order to be able to easily see which version maps to which commit and vice versa?
Go to Source
Author: Arseni Mourzenko
I am using Git Bash in Windows 10, version:
git version 2.25.1.windows.1. Let me know if I need to be more specific. I am also using GitExtensions but my question is around merging from Git Bash.
When I merge from there, i.e.:
git merge feature-branch-name
it commits even though, as far as I can tell, all three of my Git config files are set otherwise. I know I can specify
--no-commit in the command but I would like not to have to do that.
From the source code directory,
git config --list produces the output below, where it shows three times that
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
core.editor="C:\Program Files\Notepad++\notepad++.exe" -multiInst -notabbar -nosession -noPlugin
core.editor="C:/Program Files (x86)/GitExtensions/GitExtensions.exe" fileeditor
mergetool.winmerge.path=C:/Program Files (x86)/WinMerge/winmergeu.exe
mergetool.winmerge.cmd="C:/Program Files (x86)/WinMerge/winmergeu.exe" -e -u -wl -wr -fm -dl "Mine: $LOCAL" -dm "Merged: $BASE" -dr "Theirs: $REMOTE" "$LOCAL" "$BASE" "$REMOTE" -o "$MERGED"
difftool.winmerge.path=C:/Program Files (x86)/WinMerge/winmergeu.exe
difftool.winmerge.cmd="C:/Program Files (x86)/WinMerge/winmergeu.exe" -e -u "$LOCAL" "$REMOTE"
git config --get merge.commit outputs
FYI, GitExtensions behaves correctly: merging there does not commit.
What am I missing?
Go to Source
Author: Craig Silver