One of my steps suddenly started failing with the error:
reqKick|executeStep|step|prepData|jFrogPipelinesSessionId:28be9c21-4ad6-4e3d-9411-7b9988535fd1|_getResourceVersions,
All resource versions are not fetched. Requested resource versions: 16; received resource versions: []
Not sure what went wrong, I'd just reset my input resource.
How can I get my step back to working state?
If any of the resource were reset after the run was triggered. This scenario can happen.
Re-running the pipeline should work as expected.
Because when a resource is reset, it wipes out the resource version history and resets it to a single version, which is now considered the latest. This version is used for the new run. As the resource reset happened after the run was triggered, you faced the above error.
Related
The idea is that I want to block pull requests on GitHub if a build fails on Jenkins so that potential bad code doesn't get merged
I had originally found a plugin called Pipeline GitHub Notify Step: https://www.jenkins.io/doc/pipeline/steps/pipeline-githubnotify-step/ that uses
githubNotify
but then I found out from this link https://plugins.jenkins.io/pipeline-githubnotify-step/ that we should use the github-checks-plugin instead of the Pipeline GitHub Notify. I don't know if its because its depreciated or they just added similar features to the github-checks-plugin but I decided to just install the GitHub Checks Plugin. Afterwards I opened a PR on GitHub with code I knew would fail the build then ran a test build on Jenkins with the impression that GitHub would block my PR due to the bad build but it didn't I went under settings->branch and enabled Require status checks to pass before merging but it didn't block my PR because of the failed build. In fact it still doesn't even notice the failed build. Maybe I'm missing another plugin or perhaps there was something I forgot to enable.
I've got Azure DevOps release pipeline for our web apps with two stages:
staging (production slot) and production.
Both of those stages have a task to run integration tests against those environments as the final step.
Sometimes, due to the nature of the live environment (data), some of the tests may fail. That doesn't mean there's an issue with the app.
Once that happens, the release to that environment is marked as Failed (rejected), which is correct from process point of view, but then manual inspection can reveal that it was only a data issue, thus it's ok to keep it.
Is there any way to manually change the status (via GUI or API)? So it no longer appears as Failed on the dashboard.
I can't find anything in the GUI. I was able to find Manual Interventions in the API (https://learn.microsoft.com/en-us/rest/api/azure/devops/release/manual%20interventions?view=azure-devops-rest-5.1), but without any details on what it does.
Redeployment is not guaranteed to be successful from data perspective hence the need to manually override the status.
Edit:
This is what I'm currently getting when it fails, but I'd like to be able to turn the red stage into green.
You can try using option "Trigger even when the selected stages partially succeed" that is available in the pre-deployment condition.
Then I saw option to manually deploy the prod environement.
I am new in project continuous deployment. I only add my project in Travis CI and add the status logo in my github repo README.md. My project is created using php,html,javascript,bootstrap. And, my project is also connected with mysql database.
Now, what can I do so that it results successful build status.
Edit 1
As I new I don't know where the error message stored by travis ci. But, I can see a job log.
The job log is where you can find out what went wrong. Simply read the logs generated by travis, i.e. here: https://travis-ci.org/al2helal/HandicraftStore/builds/373415975
The error message you're getting is:
The command "phpunit" exited with 2.
Since you haven't defined what you want Travis to do in your .travis.yml, but only configured the language (php), Travis runs the default set of tests for the configured language. In your case it runs phpunit.
However, you haven't written any tests nor you have configured phpunit, so it only displays a help message and exits with an error code.
Before you deploy your automatically anywhere you should run tests that confirm your application is working as expected. Start with writing some.
Next, you'll need to configure Travis to run those tests and configure deployment if all tests pass.
Since you don't seem to know anything about Travis CI, the best place to start is just go through their docs: https://docs.travis-ci.com/
I have set up Jenkins and Github such that whenever I push a commit to an existing pull request, it automatically adds a comment and triggers a Jenkins build. Prior to today, Jenkins amended that comment with the status of the build and the functional tests executed. (So I know that part works.)
Today, I updated Jenkins and Jenkins ceases to notify Github of the build status. When I check the Jenkins configuration, the post-build section says:
Set build status on Github commit [deprecated]
This notifier will set GH commit status. This step is DEPRECATED and will be migrated to new step in one of the next major plugin releases. Please refer to new universal step.
Are they saying they removed functionality and I need to either downgrade or wait for them to restore it when they get around to releasing an update?
Alternatively, if they want me to start using this new "universal step", where can I find the documentation on setting that up?
I looked at Show current state of Jenkins build on GitHub repo but it appears the answers to that question are now obsolete (answered six months ago).
I am currently using Jenkins version 2.3, Github plugin 1.19.1 and Github API plugin 1.75.
I think you may have been bitten by this issue: https://wiki.jenkins-ci.org/display/JENKINS/Plugins+affected+by+fix+for+SECURITY-170
It says
If using the standard ${sha1} branch spec, builds will fail with "Couldn't find any revision to build".
Pull requests remain in the "pending" state as the plugin fails to update the PR with the build outcome
It sounds like this can be fixed by using a whitelist of terms. In my case, this was handled by another engineer, so I can't provide firsthand details.
In my TeamCity instance I have a build that builds, packages and publushes a NuGet package from source.
This particular package has version hardcoded in build parameters and isn't being incremented on each build.
On the final step of the build, actual publish, in case I am trying to publish a package with the version that is already published, I get an error (NuGet Publish type step returns 1).
This return code marks entire build as failed, since there is a general condition to fail a build where any steps return anything other then 0.
I would like to have a third state of the build - partially successful, to indicate that even though everything went fine, the publish didn't happen. Is this possible via some trick in configuration? Any type of result would be sufficient, as long as it is not marked red as failed and is not totally green that won't let me see that it didn't publish.
There's no "warning" result for a build config in TeamCity.
My suggestion would be that you move the Package/Publish steps into a separate build config that is triggered by a finish build trigger (success only) on your Build config. That way the build config can succeed, and the Package config may fail independently - you will see the results of both which should give you what you want.
Alternatively you can query your Nuget server if the package with the version you are about to produce already exists and do nothing in this case (or handle it differently). That should be doable with a little Powershell.