I am an admin on our Jenkins master but, this button is not available for any builds for any user.
I found this question which has a somewhat relevant answer since we are also using Matrix-based security, however no one has this button showing up on any build
Is there a plugin required to have this feature available?
My version isJenkins ver. 2.105
Keep forever option appears only when relevant, meaning only if you opt in on other option Discard old builds. If not it's irrelevant see jenkins users answer
option only appears if you have chosen to Discard Builds
from the config for the job. (i.e. if you have chosen not to discard
any builds have a certain time/build number, then the button won't
show).
Related
Our team has a freestyle project in Jenkins that allows us to build with a specific TFS change set and deploy to a testing environment. Both of these options are parameterized, but recently, these parameters are no longer visible in the job history sidebar for new jobs.
We expect to see both a change set number if one is provided, but the environment is a required parameter and should always be visible. Since the parameters are visible for builds older than May 11, I thought this was adjustable at the project level and was accidently modified, but I do not see an option for this in the project. I am able to confirm that the project is still parameterized, and builds are still able to be filtered by environment:
Is there an option to adjust the visibility of these parameters in the sidebar so that they appear again for new builds, or is something else happening here?
Currently the links tab of a PBI (or BUG) shows the commits as well as the pull requests but I would like to see the build in which those commits were included as well as the releases of that build (when it was released and to which Server)
In short, is there any way to configure TFS to see the build and release details from within the PBI/BUG Details page?
Currently our approach to find out whether a specific PBI has already been deployed, is to start from the Build and Release menu and to click through all recent releases and their builds until we find the PBI we are interested in. That is not an efficient Approach.
I found this and consider it as the answer to my question.
https://blogs.msdn.microsoft.com/devops/2017/08/25/automatic-linking-work-items-to-builds/
I'm trying to use Configuration Slicing plugin to discard build and artifacts for a lot of different jobs in jenkins. However, I'm not exactly sure on how to configure it.
Discard Old Builds Slicer - Days to keep artifacts
The Item Names I understand would be the list of jobs we would like to discard the builds for. The configured value section has disabled by default. Should I make it enabled?
Where should I specify the #Days to Keep the artifacts? Is it in the dialogue box below?
Can anyone please provide examples on how to configure this? I'm trying to configure this in a live environment. I would like to be sure before making any changes.
Tia,
Lakshmi
I hope this helps.
Try to fill in the number of days for which you want to see the older builds where it says (Disabled) by default. Fill in the name of the jobs you want to apply the rule to under Item Names. Then Save.
For the changes to reflect you need to run the jobs once. This worked for me.
You can also use the Discard Old Builds Slicer - Max # of builds to keep with artifacts if you want to restrict to a certain number of builds. Configure it the same way.
Please see the screenshot attached.
Screenshot of Discard Old Builds Slicer - Days to keep artifacts
I am new user to jenkins. My jenkins version is 1.594. When we got the confirmation from jenkins team about onboarding the jenkin job, i did not find the build now option for the job.
I just bumped into the same problem, but none of the mentioned solutions worked. I had created a new job using the Copy from functionality. I was then sent to the job configuration page. I left this page without pressing Save or Apply, and the Build now link did not appear. I then went back to the configuration page, pressed Save, and the Build with parameters link became visible.
Add one more possible answer:
Under some circumstances, you may automatically logout and stay at the same page(no button available), try login again fixed my problem...
Build now option does not come in either of the below reasons:
Project might be disabled. Please enable it or ask the concerned team to enable it.
You do not have enough permission to build the project. Please raise the concerned permission.
You can choose "This build is parameterized" in configure and add a dummy Boolean parameter, check default value.
Then you will get a build button
Another reason why "build now" might not appear is if your Jenkins couldn't find your Jenkinsfile. Scan your project and check the log.
If you find a line that says 'Jenkinsfile' not found, then that's your problem. Check the git repo and make sure the file is there and make sure there isn't a typo in the name.
In my case, I had accidentally hit the red X on Behaviors (under Branch Sources with a multi-branch pipeline). The default behavior "Discover branches" should be there. You can put it back by choosing the Add option below.
I am using TFS 2010 and have a build machine that contains a single build controller running 2 agents.
I have worked out that I can assign a tag of "Nightly" to my 2nd agent and then edit the Build Definition for my Nightly Builds in TFS to only use an agent that has the tag of "Nightly".
Easy enough.
However, the issue here is that if a normal build (Such as dev/CI) came along, it could - in theory- use my nightly agent, which I don't want to happen.
I could go around all our development builds (20+) and add in a tags=normal and tag my primary build agent with normal, but this then relies on people remembering to tag up new builds in the future.
Is there a way to set up my build agent in TFS's Server Admin, so that it will ONLY run items with specific tags? Or is my "go around the houses" approach the only logical way?
Edit
I got around this in the end by making all my builds look for "matchExactly" on empty tags, which means my "nightly" tagged agent will never be used for CI.
I believe the default for build definitions says MatchExactly and has an empty Tags Filter field. This means that by default build definitions will only run on Build Agents that have ZERO tags. So the behavior you desire should be the default, when you tag your build agent with the Nightly tag, no builds will run on that agent unless somebody explicitly goes in and changes the default Agent settings for that build def.
I expect that this agent is already running on it's own server, otherwise there'd be no reason to single it out.
You could give this specific build agent it's own build controller, that way chances of a build associated to the "CI" build controller are zero. unless people chose the incorrect Build Controller for their build definition.
This way you also won't have to go about changing the current build definitions.