Has anybody a working example of how to push a container image into a ghcr using the jib gradle plugin from within a github actions workflow?
I've tried the whole day but whatever combination of password or tokens I try I always end with the jib plugin complaining about an invalid authentication. Although I can push to the ghcr from my local computer with gradlew jib.
Really, I would be very thankful for any help.
> com.google.cloud.tools.jib.plugins.common.BuildStepsExecutionException: Build image failed, perhaps you should make sure you have permissions for ghcr.io/tobias-neubert/eclipse-temurin and set correct credentials. See https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md#what-should-i-do-when-the-registry-responds-with-forbidden-or-denied for help
You have to
allow your repository access to the package (github profile page -> Packages -> Package Settings)
Set the write permission for the GITHUB_TOKEN in your workflow (permissions.packages: write)
Related
I'm trying to set up automated build for go projects. Most people just use github dependencies which don't need credentials. We have some internal dependencies however available on our private git central server. Credentials are needed however to have go access these.
A possible workaround would be to configure a global git variable inside our build machines / build dockers; something like:
git config --global url."https://user:password#private.git.server/".insteadOf "https://private.git.server/"
however this doesn't seem to be the best solution to me, since the password would be stored in a human-readable text file.
I think the git-credentials plugin should be able to help me out; could I maybe export GIT_TERMINAL_PROMPT=1 and let the git-credentials plugin fill in for me?
How could I make sure go get or go install gets access to our private repository in a secure way?
I use a workaround with GITHUB_TOKEN to solve this.
Generate GITHUB_TOKEN here https://github.com/settings/tokens
export GITHUB_TOKEN=xxx
git config --global url."https://${GITHUB_TOKEN}:x-oauth-basic#github.com/mycompany".insteadOf "https://github.com/mycompany"
This way you don't expose the password and can revoke token at any time.
Note: Go uses http when downloading dependencies, not ssh.
In order to bootstrap Gradle-Wrapper, I need to pull the Gradle distribution from an Artifactory which requires HTTP Basic-Auth. There's no way for my build environment to access the outside world - this is blocked by the corporate proxy. My problem is how to provide the credentials so that Gradle can bootstrap.
The Gradle documentation suggests putting the username & password into gradle-werapper.properties.
If I put gradle-wrapper.properties into my project then anybody who has access to my source code would would have access to my credentials. Alternatively, if I put the gradle-wrapper.properties file into my build image then all of my builds will be tied to the same credentials. Neither of these are acceptable.
What I'd much rather do is have Gradle Wrapper pick up it's credentials from environment variables. My run-time environment makes it very easy to provide the credentials in the right way - but is there a way to make Gradle consume the credentials from an environment variable?
From the documents you gave.
In {user.home} directory create .gradle folder if it does not exist.
enter gradle.properties:
systemProp.gradle.wrapperUser=username
systemProp.gradle.wrapperPassword=password
now all you need is distributionUrl to point to your URL, and gradle will handle credentials.
There are three ways to provide credentials:
In folder {user.home} \ .gradle create file gradle.properties with
systemProp.gradle.wrapperUser=username
systemProp.gradle.wrapperPassword=password
pass throw system properties ( note: username, password can be environment variables)
./gradlew -Dgradle.wrapperUser=$username -Dgradle.wrapperPassword=$password
add system properties to GRADLE_OPTS
export GRADLE_OPTS=-Dgradle.wrapperUser=$username -Dgradle.wrapperPassword=$password
currently I have the code in my dev env. And after compiling and testing I want to move it to staging env from jenkins. I am not sure how to accomplish this goal using maven commands. Any idea on it?
Thanks
Once you are sure that you have tested your code on Dev Environment, than why do you want to transfer the source code into any other area.
1. Source code repo keeps track using branches/tags
2. To transfer the artefacts using Jenkins you can simply use execute shell.
A) Download the artefact from dev environment using wget into jenkins workspace
B) upload the same into staging repository
I have a library that I want to use Travis-CI on.
It is written in Java and uses Gradle as a build system and deploy to Bintray.
When Travis-CI runs the tests, it fails because I do not store my username and password in plaintext in the git repo.
What went wrong:
A problem occurred evaluating root project 'project-name'.
Could not find property 'bintray_net_user' on com.jfrog.bintray.gradle.BintrayExtension_Decorated#18be0f81.
This is happening because I have not committed my gradle.properties.
How to I tell it not to run the deploy code, or otherwise fake it out?
I guess you're usually passing this property using -P commandLine option? The easiest fix for you might be to check if the property is available before you use it and initiate it with a sensible default if not:
if(!project.hasProperty('bintray_net_user')){
project.ext.bintray_net_user = 'default'
}
You can add user credentials stored to your .travis.yml secure environment variables.
Since you always have one of the two (local gradle.properties, or parsed .travis.yml), it will work correctly.
For now I have a batch file with commands for update projects using svn and calling maven 'clean install'. How to create some job in Jenkins for similar actions?
Should I write it to ant file (sorry if it's stupid idea, I've just heard about it but I don't know what is it exactly and what can I do with this) or there is other way?
Thanks
Like arghtype suggested, you need to be using Jenkin's own Source Code Management by configuring SVN as SCM source and supplying credentials as part of Maven build job.
If you have to use your own local working copy, you are organizing it wrong, you will lose on all the benefits of having Jenkins manage SVN changes, and in the end, this organization will give you more unsolvable problems in the future. Think about the advice people are giving here and come with up a reason why you need to have a local workspace outside of Jenkins management on a Jenkins build machine. My only guess is: your Jenkins and Development machine are the same. That again is not how it should be organized. Jenkins is a CI-server, not a personal build "automator".
Regardless, if you still want to do what you say.
What you think you want
Create a new Freestyle job
Under Build Steps, click Add build step
Select Execute Windows batch command
Write your batch execute command in there. Your working directory will be Jenkins's $WORKSPACE, so change your path accordingly to where you want to run it.
But with the above configuration, you might have as well put the batch file under windows scheduler... You are not really using Jenkins with the above.
What you should do instead
Create a new maven2/3 build job
Under Source Code Management, select Subversion
Under Repository URL enter the remote SVN repo (i.e. http://your.svnsever.com/path/to/project)
Under Build, enter your Root POM location (this will be relative to the location of your SVN checkout, so if your POM is under http://your.svnserver.com/path/to/project/maven/pom.xml, then enter maven/pom.xml.
Under Goals and options, enter clean install
Click Save
The Source Code Management section will take care of setting up a local workspace and checkout the repository into that workspace. By default, every time a new build is triggered, it will run svn update on that workspace for you.
The Maven Build step will take care of running your Maven, however note that it is configured to use default ~/.m2/repository location. If your local maven repo needs to be different, change this under Jenkins Global Configuration
Create a new job.
In Source Management choose Subversion, specify your repo and credentials.
Add a new build step - maven build, specify your maven goals ('clean install').
Jenkins is a CI(contiounus integration) server. It can be used to generate scheduled builds of ant or maven based projects. It can also start building projects by some triggering event such as a commit to SCM (git, svn, mercurial,...)connected to it. You really have to read its documentation to get a better understanding. It has nice tutorials.