Stuff I'm Up To

Technical Ramblings

Git Credentials — September 18, 2019

Git Credentials

Using git to push commits up to the remote is all in a days work. The change happens when you switch to a new remote and use a new account.

My first actions where to change the remote for my local project. This is easy enough using git remote set-url origin [url]. It was only when I went to push this project up to the new remote repository that I found I was being denied with a 403 error, which means permission denied.

The big reason for the problem was a change from ssh to https. Using ssh was pretty straight forward, as long as you have your key and it is registered in your .gitconfig for the host your pushing to the credentials are pretty robust.

I’d take a step toward running the remotes on https due to firewall and proxy issues that meant https should be easier.

But because ssh keys can make life easier by not having a key password (cool, unless your user password is weak), the change to https means you need to provide credentials on each push.

This is where you need to start looking at Git Credentials Storage.

Under Linux you can specify a credentials file that will feed your details into the process. The file should be placed somewhere every secure and with the correct permissions to ensure it isn’t misused. For instance as a hidden file under your home directory with nly you having permission to access it.

eg.

$ touch  ~/.my-credentials
£ chmod 600 ~/.my-credentials
$ git config credential.helper 'store --file ~/.my-credentials'

But with Windows things actually get a bit easier! Which is hard for a Linux head to accept :)

The git helper for Windows means that your credentials get stored with your windows account.

$  git config credential.helper manager

Because I changed remotes and changed the account I was using, under Windows I needed to remove my old credentials. This is easy enough. I just brought up the start menu and type “credentials“. Then I chose the option for “Manage Windows Credentials“. In the list of generic credentials I could see my old account and simply removed it. The next time I pushed I was asked for new credentials which then got added into the list for me.

Gitlab: When an Upgrade Goes Bad! — July 25, 2019

Gitlab: When an Upgrade Goes Bad!

Today is not a lot of fun.

I’ve been seeing some issues with apt not being able to upgrade Gitlab due to a proxy error. This morning I fixed it and the upgrade from 11.11.2 to 12.1.1 began – and failed miserably!

It complained with all kinds of problems not being able to carry out migrations:

Exception: Your database is missing the 'cache_invalidation_event_id' column from the 'geo_event_log' table that is present for GitLab EE.
 Even though it looks like you're running a CE installation, it appears
 you may have installed GitLab EE at some point. To migrate to GitLab 12.0:
 Install GitLab 11.11.3 EE
 Install GitLab 12.0.x CE 

This was just the start of my problems.

Continue reading
Gitahead — February 1, 2019
Yarn, npm and Git — July 31, 2018

Yarn, npm and Git

I’m kinda new to this hosting software externally. I’ve been happy using Gitlab for internal private projects, but recently I’ve been forking and reworking the work of others to include into my own.

So I thought I’d try publishing them back out to npmjs.com and github,com.

Publishing up to github is pretty straight forward. Using git from the command line to just add, commit and push is all the same, just now with an online repository rather than the internal Gitlab. In fact once the repository is added to the project I’m betting the Atom.io built in Git will handle the committing and pushing.

Recently I decided to have a look at yarn – it uses the npmjs repository just like npm. So far I’m liking it. It’s kinda pretty and I do like the caching.

I pretty much use yarn where ever I would have used npm. So instead of npm init I use yarn initnpm install I now use yarn add. Where I used npm run dev now it’s yarn run dev, and yarn run hot, etc.

Publishing

Now to push my packages up to npmjs. First you have to have an npmjs account, so sign up. Like Github, npmjs is only free for “public” packages. If you want “private”, you have to pay.

Then link yarn and npm up to your npmjs account using login.

$ yarn login
yarn login v1.7.0
question npm username: mynpmjsname
question npm email: me@mail.com 
Done in 32.16s.

Similarly for npm.

This saves an auth token into your .npmrc file so if you’ve supplied the password already you won’t need it to publish with. What I found after pushing up to git and publishing to npmjs was that I was doing things in the wrong order. So used to doing git commit and push, it’s second nature.

Before you git push to github, publish the package to npmjs. Do it this way because it will force a version increment which will do a git commit. Because it will have incremented the version in your package.json.

The name, version and description etc. in your package.json is what will be used by your project.

Because you are likely to want to publish what is probably a private project name (beginning with @) to a public project you’ll need to tell your publish command to make it public, or you’ll get a warning pretty much about about not having subscribed to publish private projects.

$ yarn publish --access=public

When you look at your projects in your npmjs.com profile you’ll see your fresh project ready for everyone to consume!

$ yarn publish
yarn publish v1.7.0
[1/4] Bumping version... 
info Current version: 1.8.1 
question New version: 1.8.2 
info New version: 1.8.2 
[2/4] Logging in... 
[3/4] Publishing... 
success Published. 
[4/4] Revoking token... 
info Not revoking login token, specified via config file. 
Done in 8.85s.

But that’s how easy it was to publish up to npmjs!

Now you’ve pushed to npmjs, you can do a git push to deliver the same project up to Github.com now with the new version.

References

https://yarnpkg.com/en/docs/creating-a-package

Git – Version Control — October 13, 2017

Git – Version Control

We have a distinct lack of version control in the relatively small development team that manages one of our business applications. One of the main challenges isn’t really related to the developers, but to the vendor that connects remotely and “fixes” things without leaving any clue as to what has been changed.

So I came up with a sneaky plan to deploy Git onto the servers and manage the versions of configuration files used by the application. I can then capture any changes and roll back as necessary.

Continue reading

Github — December 12, 2016

Github

I’ve had a few little dealings with Github in the past as a contributor, but thought as I’m working on a project that borrows from a lot of code that is “sociably” hosted on Github by many Open Source developers, I thought I’d take the opportunity to put something back.

So what is Github?

It’s a location for Gits! So more importantly what is Git? Git is a version control mechanism that allows you to manage and maintain a folder structure, recording and monitoring changes as you develop. So Github is an online repository to publish your Gits.

Once published the whole world can see your code and your changes. Not only that they can clone your work, make changes and submit the changes back to you for inclusion in your project.

Continue reading