git reflog is showing plain text password used

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
Author: Derek

How to Fix Gradle Wrapper Permission Denied Error

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?

ANSWER

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/

How does CI deployment to AWS typically work at scale?

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

Can there be a git flow that allows branches to be merged staging/development but not to master?

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:

  1. 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 staging to master.
  2. In 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.
  3. 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 stanging and 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
Author: vedant

What’s in THIS environment?

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
Author: DaveTX

How do I map commits from a DVCS to the actual version numbers?

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 2.4.0.18522, 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 2.4.0.15, “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 2.4.0.15?”
  • “What could have broken [a given feature] in version 2.4.0.15?”
  • “Let’s do a hotfix. From which commit exactly should we create the hotfix branch?”
  • etc.

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

Why is Git Windows committing on merge, even with merge.commit=no?

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 merge.commit=no.

diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=false
core.fscache=true
core.symlinks=false
core.editor="C:\Program Files\Notepad++\notepad++.exe" -multiInst -notabbar -nosession -noPlugin
credential.helper=manager
merge.ff=no
merge.commit=no
core.editor="C:/Program Files (x86)/GitExtensions/GitExtensions.exe" fileeditor
user.email=craig@wereallconnected.ca
user.name=Craig Silver
merge.tool=winmerge
merge.ff=no
merge.commit=no
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"
pull.rebase=false
fetch.prune=false
rebase.autostash=false
diff.guitool=winmerge
difftool.winmerge.path=C:/Program Files (x86)/WinMerge/winmergeu.exe
difftool.winmerge.cmd="C:/Program Files (x86)/WinMerge/winmergeu.exe" -e -u "$LOCAL" "$REMOTE"
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
core.sshcommand=ssh
merge.ff=no
merge.commit=no
submodule.active=.
remote.origin.url=REMOVED
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.puttykeyfile=REMOVED
branch.master.remote=origin
branch.master.merge=refs/heads/master
branch.FMS-1203_data-structures-algorithms-string-matching.remote=origin
branch.FMS-1203_data-structures-algorithms-string-matching.merge=refs/heads/FMS-1203_data-structures-algorithms-string-matching
branch.FMS-1205_recency-trumps-frequency-for-small-fr-diff.remote=origin
branch.FMS-1205_recency-trumps-frequency-for-small-fr-diff.merge=refs/heads/FMS-1205_recency-trumps-frequency-for-small-fr-diff
branch.FMS-1204_debug-window.remote=origin
branch.FMS-1204_debug-window.merge=refs/heads/FMS-1204_debug-window

Also, git config --get merge.commit outputs no.

FYI, GitExtensions behaves correctly: merging there does not commit.

What am I missing?

Go to Source
Author: Craig Silver