I have the short hash like 3cdd5dabcd. How do I use libgit2sharp to retrieve the full hash like:
git rev-parse 3cdd5dabcd
I am thinking using the process to call git directly if libgit2sharp does not support this.
You need to look up the blob by the short ID. The Blob object will have the full Id as a property:
repo.Lookup<Blob>("3cdd5dabcd").Id;
Related
Currently my Jenkinsfile looks like following:
def git_credentials_id = '6cf44519-d541-458f-9ef2-78cada281dca1'
def git_url = 'git#gitlab.corp.local:Group_name/repository.git'
def evaluation_dataset_path = '/mnt/data/evaluation_dataset/'
pipeline {
parameters {
string(
...
}
}
Now we plan to collaborate with another team, that uses their own infrastructure (own Jenkins; own repository, even not git, P4; etc).
This makes irrelevant first three lines of the file.
There is also a checkout stage, tied to git, but, I hope that refactoring of checkout command would be similar to refactoring of the credentials.
How can I split this Pipeline code, so that both teams could use its "immutable" part and substitute their own credentials and paths?
What are the best practices here?
I've found an answer.
Put these values into properties file and read them using utility-steps plugin.
https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/docs/STEPS.md#configuration-files
I'd like to generate a series of usernames/passwords to be used with JHipster's Spring Security. My plan was to insert these into src/main/resources/config/liquibase/users.csv but I'm having trouble generating the encrypted password to go into this file.
I expected to be able to do something like this:
def encoder = new BCryptPasswordEncoder()
println encoder.encode('admin')
but the produced String ("$2a$10$icbkSBY4H/ub8pKAcnYhjeCit3A6e8JszUVZfu74sG6qqrSoT9CYW") does not match the known value in the default users.csv file ($2a$10$gSAhZrxMllrbgj/kkK9UceBPpChGWJA7SYIb1Mqo.n5aNLq1/oRrC).
Can someone please explain what I'm missing here?
Thanks!
--john
That's ok. BCrypt generates a new hash each time, because a part of this string is a random salt. Bcrypt encoder can compare such hashes, because it knows where to get salt and actual hash, so it can encrypt password using this salt and compare result with actual hash.
Your $2a$10$icbkSBY4H/ub8pKAcnYhjeCit3A6e8JszUVZfu74sG6qqrSoT9CYW contains:
icbkSBY4H/ub8pKAcnYhje as salt
IjZAgcfl7p92ldGxad68LJZdL17lhWy as hash
So first of all, it's ok to get different encrypted passwords each time even for same raw password. Second, you don't need to compare it manually, use PasswordEncoder.matches
You can also use any online BCrypt password encoder, instead of writing code for this. There're plenty of them.
See also: https://en.wikipedia.org/wiki/Bcrypt
Here is my scenario, i'm using resque to queue a job in redis, the usual way its done in ROR. The format of my key looks something like this (as per my namespace convention)
"resque:lock:Jobs::XYZ::SomeCreator-{:my_ids=>[101]}"
The job runs successfully to completition. But the key still exists in redis. For a certain flow, i need to queue and execute the job again for the same parameters (the key will essentially be same). But seems like the job does not get queued.
My guess is that since the key already exists in Redis, it does not queue the job again.
Questions:
Is this behavior of resque normal (not removing the key after successful completition)?
If Yes, how should i tackle this scenario (as per best practices)?
If No, can you help me understand what is going wrong?
After a couple of hours of debugging, finally this is the observed behavior:
I was creating the job and passing the options (parameters) with symbolized keys which when created the Redis key for the same job with symbolized param in the key.
Example:
Jobs::Abc::SomeJobCreator.create({:some_ids => [101]}) would create the "redis key" as "resque:lock:Jobs::Abc::SomeJobCreator.create({:some_ids => [101]})" (Notice the key being a symbol in the key)
Now when the after_perform_hook executes, it tries to remove the Redis Key but it searches the key with Stringified keys: "resque:lock:Jobs::Abc::SomeJobCreator-({\"some_ids\"=>[101]}" Which obviously won't be found, as the key in Redis has symbolized params in key.
To fix this issue i had to change the calls to job creation in the code and use stringified params like this: Jobs::Abc::SomeJobCreator.create({'some_ids' => [101]}). This works fine.
Not sure if this has anything to do with the version of Resque. Since its a old codebase i haven't yet updated the version. Its currently at Resque v1.25.2
As per the resque-status home page on GitHub I should be able to pass back data from a job. For some reason this does not seem to be working for me. If anyone else has encountered this problem and worked around it I would like to know how.
I am using resque-status with JRuby 1.6.5 in a Rails 3.2.3 application.
Passing back data from the job
You may want to save data from inside the job to access it from outside the job.
A common use-case is web-triggered jobs that create files, later available for download by the user.
A Status is actually just a hash, so inside a job you can do:
status['filename'] = '/myfilename'
Also, all the status setting methods take any number of hash arguments. So you could do:
complete('filename' => '/myfilename')
Apparently such functionality is not implemented, as read on
https://github.com/quirkey/resque-status/issues/66
we've found a work around using the function set_status to add the required data to the status hash:
set_status({"my variable" => "my value" })
hope this helps!
We recently lost a database and I want to recover the data from de Production.log.
Every request is logged like this:
Processing ChamadosController#create (for XXX.XXX.XXX.40 at 2008-07-30 11:07:30) [POST]
Session ID: 74c865cefa0fdd96b4e4422497b828f9
Parameters: {"commit"=>"Gravar", "action"=>"create", "funcionario"=>"6" ... (all other parameters go here).
But some stuff to post on de database were in the session. In the request I have the Session ID, and I also have all the session files from the server.
Is there anyway I can, from this Session ID, open de session file and get it's contents?
It's probably best to load the session file into a hash -- using the session-id as the key -- and then go through all the log files in chronological order, and parse out the relevant info for each session, and modify your database with it.
I guess you're starting out with an old database backup? Make sure to do this in a separate Rails environment -- e.g. don't do this in production; create and use a separate "recovery" environment / DB.
think about some sanity checks you can run on the database afterwards, to make sure that the state of the records makes sense
Going forward:
make sure that you do regular backups going forward (e.g. with mysqldump if you use MySQL).
make sure to set up your database for master/slave replication
hope this helps -- good luck!
Have you tried using Marshal#load? I'm not sure how you're generating those session files, but it's quite possible Rails just uses Marshal.
A client exactly had the same problem a few weeks ago. I came up with the following solution:
play back the latest backup you have (in our case it was one year
old)
write a small parser that moves all the requests from production in a temporary database (i chose mongodb for that): i used a rake task and "eval" to create the hash.
play back the data in the following order
play in the first create of an object, if it does not already exist.
find the last update (by date) and play it back.
here is the regex for scanning the production.log:
file = File.open("location_of_your_production.log", "rb")
contents = file.read
contents.scan(/(Started POST \"(.*?)\" for (.*?) at (.*?)\n.*?Parameters: \{(.*?)\}\n.*?Completed (.*?) in (.*?)ms)/m).each do |x|
# now you can collect all the important data.
# do the same for GET requests as well, if you need it.
end
In my case, the temporary database speeded up the process of the logfile parsing, so the above noted steps could be taken. Of course, everything that was not sent over production.log will be lost. Also, updates of the objects would send the whole information, it might be different in your case. I could also recreate the image uploads, since the images were sent base64 encoded in the production.log.
good luck!