i have gitlab omnibus, 8.0.4 version, installed on private server, we need to remove access right from reporter to read/pull/download code,
so we dont want reporter to viewer the source code
I think it can be done through editing some file on the server, right?
how can we do it?
Reporter always has read access to files, issues and merge requests. This cannot be altered (and we do not recommend modifying source files since it makes upgrades more difficult).
My suggestion is to create a separate project with only the issue tracker enabled and add the user as a reporter there. Keep the project with source code private.
Danger section ;)
If you really want to modify the code, look in app/models/ability.rb. In the project_report_rules method remove the rights you do not wish 'reporter' to have.
Related
There is an unstable gitlab server and I am not sure that it will be able to work in the future. Therefore, I want to make a backup copy of all the repositories (projects) that are there.
Cloning the source code will be enough, but it will be great if there is a way to save issues as well. Are there any ways to do this?
It depends on what kind of access you have, but if you don't have administrator access to do a full backup, then the best thing to do is to use a couple of API endpoints to get the information you need and go from there.
Use the Projects API to get a list of all projects accessible to you.
Note the pagination limits.
What you store depends on how you want to get the information.
Store at least the ID number of each.
Filter by membership if you only want the ones you're a member of.
Filter by min_access_level = maintainer (or higher) if you want to export whole projects.
Use the Project export API to trigger a project export for each project you're a member of, and you're a maintainer (or higher).
For all other projects where you have a lower role, or where it's public, you could still use git clone for the repositories by storing the ssh_url_to_repo or http_url_to_repo from the Projects API and running through each.
For all other parts of a project, you could store the JSON version to recreate them later if you want to go through the hassle. For example, for issues, use the Issues API.
I need help. I've created a new release of my tool in GitLab and the zip files were created successfully. I can now download them via this URL:
https://gitlab.xxx.de/xxx-development/xxx-helper/-/archive/v1.0.0/xxx-helper-v1.0.0.zip
The problem is that I need to remove the -v1.0.0 somehow from the file name of the zip file because otherwise a target system creates a folder with the version in the name which makes huge problems. So at least I need this structure:
https://gitlab.xxx.de/xxx-development/xxx-helper/-/archive/v1.0.0/xxx-helper.zip
How can I do this?
The naming of releases is automated, and changing it would require updates to several parts of the Gitlab stack/codebase.
Answer: it's technically possible but not simple.
One portion that serves as a functional example to illustrate; guest users of private projects are allowed to view the Releases page but are not allowed to view details about the Git repository (in particular, tag names). Because of this, release titles are replaced with a generic title like “Release-1234” for Guest users to avoid leaking tag name information.
This is the URL you are referring to, and asking to change. It uses the generic title.
I can point to some parts of the codebase, but probably not all easily - it would require some significant effort. This is a project. It would also matter if you are using CE or EE.
I’m trying to set up GitLab CI/CD for an old client-side project that makes use of Grunt (https://github.com/yeoman/generator-angular).
Up to now the deployment worked like this:
run ’$ grunt build’ locally which built the project and created files in a ‘dist’ folder in the root of the project
commit changes
changes pulled onto production server
After creating the .gitlab-ci.yml and making a commit, the GitLab CI/CD job passes but the files in the ‘dist’ folder in the repository are not updated. If I define an artifact, I will get the changed files in the download. However I would prefer the files in ‘dist’ folder in the to be updated so we can carry on with the same workflow which suits us. Is this achievable?
I don't think commiting into your repo inside a pipeline is a good idea. Version control wouldn't be as clear, some people have automatic pipeline trigger when their repo is pushed, that'd trigger a loop of pipelines.
Instead, you might reorganize your environment to use Docker, there are numerous reasons for using Docker in a professional and development environments. To name just a few: that'd enable you to save the freshly built project into a registry and reuse it whenever needed right with the version you require and with the desired /dist inside. So that you can easily run it in multiple places, scale it, manage it etc.
If you changed to Docker you wouldn't actually have to do a thing in order to have the dist persistent, just push the image to the registry after the build is done.
But to actually answer your question:
There is a feature request hanging for a very long time for the same problem you asked about: here. Currently there is no safe and professional way to do it as GitLab members state. Although you can push back changes as one of the GitLab members suggested (Kamil Trzciński):
git push http://gitlab.com/group/project.git HEAD:my-branch
Just put it in your script section inside gitlab-ci file.
There are more hack'y methods presented there, but be sure to acknowledge risks that come with them (pipelines are more error prone and if configured in a wrong way, they might for example publish some confidential information and trigger an infinite pipelines loop to name a few).
I hope you found this useful.
I've been using git for a little while now in a new project I am working on.
I decided to use GitLab.com as I would like the opportunity to keep me repos private until I'm ready to share them (which github doesn't allow me to do).
The whole beauty of git for me is that I have a copy of the whole repo on my local machine and on the remote site.
However I make lots of comments, on my 'local' gitlab instance.
I know that I can put the wiki into source control, is it possibly to do the same thing with the comments and milestones (or in some other way share them between repositories)
I feel that this should be possible.
Maybe using an rss feed to push and pull the data to / from the various locations.
Or can I use the issues as a 'mailing list' somehow, with a 'mail into list' (however I would then need to get my local gitlab instance to mail any new issues to the remote - could probably be setup using some form of 'auto forward' filter in my mail client / gmail.
Are any of these ideas even possible ?
Is there a better solution - I'd prefer something that will integrate into my gitlab instance (local and remote), rather than needing having to use a separate interface ~ I like everything to be in a single place if possible.
Remember also I like to have access to my issues etc when offline (and then have them 'sync' when I go back online).
Thanks for any help in advance.
David
You could build a script and make use of the API to sync your issues and notes. Maybe a script that pulls all of the new issues and notes and POSTs them to the equivalent projects on GitLab.com. You could run the script manually or create a cron job to post the new items periodically.
I have a team that will be using CruiseControl for continuous integration, and CC will be running on a Linux server. More than one team member may need to access the CC configuration itself: changing how tests are run, changing notification rules, etc.
What is the best practice for this?
My first thought was to set up a cc-users group, then make a shared directory somewhere (such as /usr/local, I suppose, or a new directory like /projects), where the directory has r/w for the group.
Am I missing any complications with this plan? Obviously, I've never been in charge of such a project before, otherwise I wouldn't ask such a question.
FWIW, my intention is to have all the cc configuration files under mercurial so we can roll back in case of breakage.
I have version-controlled the whole of cruisecontrol configuration, along with the project specific config files underneath it.This way, the write-access can be controlled per requirement, using your source control tool's access control method (in our case subversion) thus providing tracking as well. Whomsoever needs to make a change can checkout the file config.xml in their own workspace and make their changes and then commit. You may want to consider the same approach.