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.
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 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.
So I'm using Visual Studio 2012, and whenever I create a new project I always leave out the "Add to source control" option, mainly because I don't what it is, what it's purpose is, or if it would be beneficial to me to use it.
I'm developing a rather large library on my own. I plan on making it open source. Is this what source control is for? Reading up online did not help me unfortunately, I'm still desperately confused. Is source control the same as version control too, by the way?
Some clarification would be greatly appreciated.
Thanks!
Alex
Source control (otherwise known as revision control: http://en.wikipedia.org/wiki/Revision_control) is a way in which you can store and manage changes and revisions to your code-base.
Google: SVN, Git, Mercurial and Google Code, GitHub, Bitbucket.
I personally never start a propject (personal or otherwise without it). Also, I like BitBucket (www.Bitbucket.com) for managing my projects. It's free for a single user and they support Git and Mercurial.
Quite simply, source control is a repository where your source code is stored. It's purpose is to provide a storage spot that is separate to the copy that you are currently working with, so you can make changes locally and then submit them back to your source control repository.
Think of it as being like a library - you can get code out, you can return (modified) code to it. It also gets more complex than that - you can use source control to handle multiple versions of the same source, and to merge changes from one copy to another. Additionally most (all) source control systems should provide a mechanism for tracing changes to code (i.e. audit tracking), and a means to "roll back" or revert to a previous version.
There are a variety of source control systems, some of which you install locally and some which you install centrally and access remotely. In all cases the underlying philosophies are mostly the same, although there are some differences around terminology and implementation of features. Source control is considered to be a system that is separate to your editor, your editor then provides a means to specify which source control provider to use and the location of the source control repository.
I have found this
Git Source Control Provider is a plug-in that integrates git with
Visual Studio
According to this, seems like source control = version control
You were asked this when starting a project because it's much easier to setup before you have many messy pieces. Github is a form of version control. An organized place for code to grow.
Version control really shines if you're collaboratively working on a project with many different pieces to it. Source or version control is the process of taking the many different parts that are being worked on simultaneously and bringing them together as a final project.
If you're working on your own it still may be beneficial to practice with, as still holds some value in allowing a process of documentation, and modular pieces being brought together for a final project.
This wonderful post explains many of the benefits of using version control for your pet projects.
Well, there are a number of good reasons:
1. It’s good to be in the habit. Sure, you may be working alone. But in
the future you may not be. Or your “weekend hobby project” might turn
into a popular project with many developers. If anything like that
happens, being in the habit of using source code control will stand
you in good stead.
2. It protects your code. Since your code is stored
in on a server apart from your development machine, you have a backup.
And then, you can even backup the code on the server. Sure, you can
zip it all up any time you want, but you don’t get all the other
benefits I’m listing here.
3. It can save your butt. Sometimes, you
might accidently delete something. You might make mistakes and change
code that you didn’t want changed. You might start off on some crazy
idea when you are feeling a bit saucy, and then regret it. Source
control can save you from all of these by making it a piece of cake to
revert to any previous state. It’s like a really powerful “undo”
feature.
"Source control" refers to the concept of storing all files that make up the source of an application in an (usually online) repository - where one can manage with fine detail exactly what has changed in the source code between versions, manage issues, involve other people with the project, and generally provide a platform to collaboratively manage a project.
The term is usually synonymous with version control - although you can have a repository and not explicitly name versions. Version control in particular just refers to labeling major versions of your project with a hierarchical numbering scheme (1.2.4 etc.)
There are several different tools that implement different kinds of source control. For example, Git is a source control tool that sets lets you manage a project. Github is a web-site that repositories managed with Git are usually stored on. Mercurial is yet another source control tool.
Typically, source control can be complicated to understand, and usually requires significant time studying tutorials. A lot of concepts are unfamiliar to solo programmers who have only worked on small projects. Changes to source code are managed through commits, and different branches of the project can be worked on by multiple people. Changes from separate branches can be merged, and the project can be forked by another user entirely (at least for Git).
Making your library open source is a good idea, and it's not too hard to give it a home on github. I would look into some resources to find out how to set it up.
Wikipedia says:
Revision control, also known as version control and source control
(and an aspect of software configuration management), is the
management of changes to documents, computer programs, large web
sites, and other collections of information. Changes are usually
identified by a number or letter code, termed the "revision number",
"revision level", or simply "revision". For example, an initial set of
files is "revision 1". When the first change is made, the resulting
set is "revision 2", and so on. Each revision is associated with a
timestamp and the person making the change. Revisions can be compared,
restored, and with some types of files, merged.
In simpler terms, source control allows multiple people to work on the same project without everyone clobbering everyone else's changes. Changes to the same file are merged together, and conflicts can be resolved.
It also allows you to keep version history. You can roll back a file to the way it existed at any point in time, as well as maintain different branches of the program; a way to organize groups of changes.
As Si puts it, source (or version) control will save your life 20 times over.
Source control keeps a detailed history of your code. This enables you and any collaborators to:
Review the history of any code
See changes between two versions
Revert any code you just goofed up
Prevent you from losing any code
Discover which changes caused bugs / crashes
Blame whoever messes up your code
Keep an up-to-date backup of all of your code
Even if you're not working collaboratively, source control is so useful when you accidentally delete your code. I speak from experience.
I would recommend using Git or Mercurial, as they allow branching and offer a more isolated workspace for collaborators to experiment without fear of harming any code.
For online collaboration, Github and Bitbucket are great and integrate well with Git and Mercurial, respectively. They also allow you to track collaborators' changes, choose and merge changes into a central repository, and keep a detailed list of issues.
Do you use Subversion while developing a website with drupal ?
I'm not talking about modules development, but websites development (i.e. adding hook functions, modifying template file.. etc)
thanks
Yes.
Anything that's got any kind of ongoing development or is going to change over time should be version controlled.
Even if you're just doing a very small project, the value of having a version history is indesputable, and being able to make changes without worrying about overwriting someone else's updates is priceless.
Yes, its's good keep a SVN repository synced with your local instance.For that purpose you can use Eclipse.
Yes, but we are moving to git in the near future because it offers a better feature set (distributed SCM ftw) and more options for managing our code base (git submodules, stashing, better hook integration, better merging support, rebasing, and so much more). For the time being we've got our repos setup like so:
/trunk
/branches/6.x/1.x/core
/branches/6.x/1.x/sitename.domain.edu
/branches/6.x/1.x/sitename2.domain.edu
/branches/6.x/1.1.x/core
/branches/6.x/1.1.x/sitename.domain.edu
...
/tags/6.x/1.x/core
/tags/6.x/1.x/sitename.domain.edu
/tags/6.x/1.x/sitename2.domain.edu
/tags/6.x/1.1.x/core
/tags/6.x/1.1.x/sitename.domain.edu
...
Each branch is a svn copy of the trunk repo (where we do most of our development) and each tag is a svn copy of it's corresponding branch. The core branch is the primary distro that we distribute to all of our sites that share the university's look and feel, and each subsite is a site with special modules, custom theme, or any other functionality that isn't part of the primary distro. It makes moving between drupal releases a lot easier, but you can start to run into problems merging occasionally. Also you run into performance issues when the repo starts to grow, which is part of the reasoning behind moving to git.
Yes. Version control is critical. Distributed version control systems such as Git, Mercurial, and Bazaar are particularly nice, and let you start committing immediately, without the need to push those changes to a central server.
My Drupal workflow: use Mercurial and its sub-repositories feature to create independent repositories for 1) Drupal + contributed modules, 2) theme, and 3) custom modules. That way, I can clone from a single URL, get my entire project, and be able to track changes to each distinct piece independently.
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.