I'm using a company-hosted GitLab Community Edition 11.0.2.
There used to be a menu entry 'Issues' under each project.
For some projects there still is, but not for a specific one.
I remember in previous versions it was possible to turn that feature on/off via the project-settings, but I simply can't find that setting anymore.
It should be included in the Core/Free version, though (Issue Boards has a checkmark for all versions, including Core here: https://about.gitlab.com/pricing/self-managed/feature-comparison/)
How can I enable the built-in issue feature for my personal project?
(I don't need anything fancy, just a list with issues and statuses)
It sounds like it has been disabled for the project (or the company admin has just disabled Issue boards by default on the instance).
You can re-enable it if you are a Maintainer/Owner/Admin for the project in:
Project -> Settings -> General -> Permissions
Project settings documentation.
Related
I'd like to add a Quick Look extension to my program, but in order to be useful, it would have to access the Core Data stack, which seems to require me to add an App Group and a provisioning profile to the project.
Until now, it has been possible for anyone to download the project from Github and compile and run it out of the box. All project targets are set to Team: None and Sign to Run Locally. If I add my provisioning profile to the project, this will no longer work. They will have to create and add their own provisioning profile and change the Signing & Capabilities settings on each of the 26 targets (there seems to be no way to do them all at once). And the profile will have to be renewed every year.
My question is, is there any way around this? Is such a major change really necessary for what amounts to accessing a file inside the program's own bundle (and another in its Application Support folder?)
EDIT: As was pointed out to me on the Apple Developer forum, you don't need a provisioning profile as long as you prefix the group name with the development team identifier. This still won't make it build out of the box, though. You will still need a developer account and set a team on every target.
I had missed that you are supposed to have a team identifier as the prefix for the group name. That still doesn't solve the problem that my project will no longer build out of the box for anyone who downloads it from Github, but it answers the question asked in the subject line.
Noticed that Azure DevOps is no longer showing the menu options in Project Settings for the Extensions.
Does anyone else see this or know why?
I am unable to update settings for the installed extensions.
You can manage the installed extensions in the Organization settings.
Go organization settings--> Extensions under General. See document here for more information.
I have seen the same thing, and it only occurred recently. Yes, the org level extension management is still there, and that only allows for managing which extensions are available to use.
The configuration for the extension usage within each project was a separate section in the project settings - this is missing entirely. We have need to modify one of our extension configs and can no longer access it to do so.
I believe this must be an Error of type PEBKAC coming from a recent MS update to DevOps.
I use Android Studio and gradle in my office using a authenticated corporate proxy. This unfortunately means that I have to enter my proxy config including user/pass in cleartext in gradle.properties (or have it automatically propagated from Android Studio's preferences).
However, sometimes I work outside of the office, and I then have to manually go in and comment out my proxy settings each time, which is tedious.
Is there a way to make properties in a gradle file conditional so that the proxy configuration can be automatically activated by detecting if I'm on my corporate network or not? The condition itself could in turn be retrieved either by querying the network adapter for the current network, or perhaps better, by making a simple curl to a known host on my corporate network.
I'm using both Windows and Ubuntu clients but this question mostly applies to Windows.
There might be other ways to solve this I guess, perhaps changing the global gradle settings rather than the project specific ones. To be honest, I have to do a similar git config --add http.proxy, and the same for npm, bower and what not, everytime I change working environments. Other suggestions are welcome even though this question specifically asks how to create a gradle.properties which tries to connect to a known intranet host, and depending on the outcome sets or unsets properties.
I have had the same problem for a while. There was an additional problem for me that gradle.properties are checked in to our VCS with a proxy setting; and I had to take extra steps before all my commits to ignore the changes I did in that file. Additionally, I had to comment/uncomment the same piece of code multiple times in a day.
I could not come up with a conditional update system, but the second problem was resolved by inbuilt shelving functionality in Android Studio and creating changelists to keep 2 copies of the file with different settings.
I don't think there is any way to solve this problem the way you are asking for. For a simple reason: .properties files are not meant to have logic. To quote the Java docs:
Properties are configuration values managed as key/value pairs.
The dynamic settings can be achieved either via Android Studio proxy settings or writing a Gradle task that runs on project load, checks network conditions and sets system properties. I haven't tested this approach, but I think this will also update the gradle.properties file (a side-effect that you may not want). But what is being done by Gradle can also be done via a shell script that you need to execute on project load.
The way I am currently handling proxy update is by entering/saving the proxy settings in Android Studio itself, and toggling when I move between locations. It just takes a couple of commands to bring up the proxy dialog and enable/disable the saved proxy.
Since this proxy file is saved in idea.config.path/options/proxy.settings.xml, you could also try writing a shell script that can toggle the contents based on network availability.
This may not be what you were looking for, but I hope it clears up why it can't be done the way you asked for.
I use Team Foundation Server for Source Control and in my Visual Studio I unckeckd the Option: "Multiple Check Out".
But when I check out a file and modify it another user can still check out the same file and also modify it.
What went wrong??
If you have to look at this issue then you are probably not checking in enough. Its a workflow and not tool change that is required.
TFS only supports the single checkout model if all users are using Server Workspaces. The default changed in 2012 to Local Workspaces which does not support this.
https://msdn.microsoft.com/en-us/library/ms181383.aspx
Check out the MSDN documentation for how to change workspace modes.
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.