Tangentially related to: AWS CodeBuild with GitHub - only for specific directory
I have a codebuild project and a github repo with many files in it. A user may update any of these files in the git repo. I want to pass the name of the altered file(s) into my buildspec.yaml somehow; IE my merge job logic, specified in the buildspec.yaml, needs to know what files changed to do a per-file operation.
I am not talking about filters; Ie "only trigger this if X,Y,Z changed". Becuase the filter is there for a large number of XYZ, but I need to know which file(s) changed in my buildspec. IE something like $CHANGED_FILE_LIST.
I don't see this here: https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-env-vars.html
Maybe we have to do something like this: how to find out list of all changed files in git for full jenkins build and not for a particular commit?
git diff --name-only $GIT_PREVIOUS_COMMIT $GIT_COMMIT
but one would think this meta info could be provided by codebuild
I don't know if there's a blessed CodeBuild way to do this, but assuming you have access to a GitHub token in the build, you can query the GitHub metadata endpoint to get the info you need. Something like
curl -H "Authorization: token ${yourtoken}" -H "Accept: application/vnd.github.v3+json" https://api.github.com/repos/OWNER/REPO/commits/${CODEBUILD_SOURCE_VERSION} | jq '.files[].filename'
will return a list of files in the commit.
See https://docs.github.com/en/rest/commits/commits#get-a-commit for more details.
git diff --name-status $CODEBUILD_WEBHOOK_BASE_REF should do the trick
You can use git diff --name-only $$CODEBUILD_RESOLVED_SOURCE_VERSION $$CODEBUILD_WEBHOOK_PREV_COMMIT
Where $CODEBUILD_WEBHOOK_PREV_COMMIT is the commit id of the previous commit. And $CODEBUILD_RESOLVED_SOURCE_VERSION is the commit id of the actual one.
Inside a build phase you can check the change with:
-
|
if [ "$(git diff --name-only $CODEBUILD_WEBHOOK_PREV_COMMIT $CODEBUILD_RESOLVED_SOURCE_VERSION | grep -e <filde_path>)" != "" ]; then
#your code;
fi
I am running version 0.8.4 as a container in my lab. CLI is also at version 0.8.4
I am trying to use a secret in a command one of my containers is trying to run.
Following the documentation has me needing to sign a repo to allow the job to consume the secret. The drone CLI does not seem to have a
drone sign command for me to run. So I create the secret with a --skip-verify=true flag. This creates the secret but when I run the job it errors out. The output in the UI shows a blank space where the secret should be injected.
Here is an excerpt of my .drone.yml where I am trying to inject secrets -s production -u ${cf_user} -p ${cf_password} --s
I have tried all the following ways to create a secret:
drone secret add <repo_name> --name <key> --value <value> --skip-verify=true
drone secret add <repo_name> --name <key> --value <value>
GUI Creation
I notice when I create an all capital name value the UI represents the value in all lowercase when the CLI shows it in capitals.
I also notice that if I include hyphens in the name and try to use that in my drone.yml the job errors out immediately with a bad substitution error.
Any help understanding what I am doing wrong would be much appreciated!
I got lost in the different documentation available. Should have been looking here rather than secret-guide.
In case I am not alone, I needed to add a secrects block in my pipeline.
I also needed to access them with $SECRET_KEY rather than ${SECRET_KEY}
pipeline:
publish:
image: governmentpaas/cf-cli
secrets: [ cf_user, cf_password ]
Just a little update on this one, I stumbled over it as well because the docs are inconsistent.
In the 0.8.5 version the only thing I had to do is:
add secrets via CLI or UI
add secrets array to utilise it
no need to pass variables to environment.
I am trying to script a brute-force ssh attack with msfconsole -x <command> using a .sh and I need to check if the command has been successful or not so I need a return value.
Looking at the docs I wasn't able to find any information about this topic.
You can use -o to create a file with the result of the brute force and then you can read the file using Bash.
Is it possible to delete old builds in Gitlab CI?
I tested a few things and have now about 20 builds that are useless (most are failed anyway).
It also shows stages that I don't have anymore which kinda clutters the Pipelines page and some of the uploaded artifacts are a bit big.
I wasn't able to find any documentation on this, only that disabling CI in the settings doesn't remove the builds.
Using Gitlab 8.10 Community (hosted by Gitlab.com)
There is currently no option in the GUI to completely get rid of a build other than expunge related data from the build. (The erase option in the build)
If you would have a local installation you could modify the database directly but I would advise caution. (I'll put the guide here for completeness sake)
Login to the GitLab database. If you use the default PostgreSQL :
sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -h /var/opt/gitlab/postgresql -d gitlabhq_production
Check if there is a table ci_builds. For pSQL: \dt
Delete the builds with normal SQL. For example: DELETE FROM ci_builds WHERE id = 2
(Optional) If you want to cleanup a list of commits which triggered a build you need to midify the table ci_commits.
I found a lot of examples on how to change the username for specific revisions and so on.
But what I need is this:
I did a checkout with the authentication credentials of a workmate and need to change it to my credentials for future commits.
I cannot just checkout with my credentials due to the many changes that have been done already...
Anyone familiar with this?
You can change the user with
Subversion 1.6 and earlier:
svn switch --relocate protocol://currentUser#server/path protocol://newUser#server/path
Subversion 1.7 and later:
svn relocate protocol://currentUser#server/path protocol://newUser#server/path
To find out what protocol://currentUser#server/path is, run
svn info
in your working copy.
The easiest way to do this is to simply use the --username option on your next checkout or commit. For example:
svn commit --username newUser
or
svn co --username newUser
It will then be cached and will be used as the default username for future commands.
See also:
In Subversion can I be a user other than my login name?
I’ve had the exact same problem and found the solution in Where does SVN client store user authentication data?:
cd to ~/.subversion/auth/.
Do fgrep -l <yourworkmatesusernameORtheserverurl> */*.
Delete the file found.
The next operation on the repository will ask you again for username/password information.
(For Windows, the steps are analogous; the auth directory is in %APPDATA%\Subversion\).
Note that this will only work for SVN access schemes where the user name is part of the server login so it’s no use for repositories accessed using file://.
The command, that can be executed:
svn up --username newUsername
Works perfectly ;)
P.S. Just a hint: "--username" option can be executed on any "svn" command, not just update.
Go to Tortoise SVN --> Settings --> Saved Data.
There is an option to clear Authentication Data, click on the clear button, and it will allow you to select which connection you wanted to clear userid/pwd for.
After you do this, any checkout or update activity, it will reprompt for the userid and password.
If your protocol is http and you are using Subversion 1.7, you can switch the user at anytime by simply using the global --username option on any command.
When Ingo's method didn't work for me, this was what I found that worked.
for Win10 you should remove this folder and close/open your IDE
C:\Users\User\AppData\Roaming\Subversion\auth
, also in my projects no ".subversion" folders, only ".svn"
Also, for those who happened to realize too late, that they committed with the wrong credentials, the solution (after the fact) is to change the svn author of that revision: see this question
Basically the syntax is:
svn propset --revprop -r (revision_number) svn:author (new username)
Based on Ingo Kegel's solution I created a "small" bash script to change the username in all subfolders. Remember to:
Change <NEW_USERNAME> to the new username.
Change <OLD_USERNAME> to the current username (if you currently have no username set, simply remove <OLD_USERNAME>#).
In the code below the svn command is only printed out (not executed). To have the svn command executed, simply remove the echo and whitespace in front of it (just above popd).
for d in */ ; \
do echo $d ; pushd $d ; \
url=$(svn info | grep "URL: svn") ; \
url=$(echo ${url#"URL: "}) ; \
newurl=$(echo $url | sed "s/svn+ssh:\/\/<OLD_USERNAME>#/svn+ssh:\/\/<NEW_USERNAME>#/") ; \
echo "Old url: "$url ; echo "New url: "$newurl ; \
echo svn relocate $url $newurl ; \
popd ; \
done
Hope you find it useful!
I believe you could create you own branch (using your own credential) from the same trunk as your workmate's branch, merge from your workmate's branch to your working copy and then merge from your branch. All future commit should be marked as coming from you.
You could ask your colleague to create a patch, which will collapse all the changes that have been made into a single file that you can apply to your own check out. This will update all of your files appropriately and then you can revert the changes on his side and check yours in.
Tortoise on windows specific:
I attempted the above solution to no available. In my use case, the credentials where stored in the windows Credential Manager under the Windows Credential section and TortoiseSVN refused to change them by running the --username command.
You can edit the credentials by expanding the url for your repo and clicking edit.