Problem
I have a gitlab with a lot of old repositories. I want to mention my gitlab as a reference on my CV but I do not want all the old repositories to appear there, just the more relevant ones.
Just making the projects private is not enough as this leaves a lot of clutter in my dashboard and it is hard to see the projects I am trying to showcase.
I do not want to delete the old projects, as I want access to them in the future, I just want to hide them from other people to see that they even exist.
What I Tried
I tried archiving the old projects but they still appear on my Projects lists, just with an archived tag.
I saw mentions of playing with the "Metrics Dashboard" under the visibility settings but this is greyed out for me + I do not think this is what I need from my understanding.
Required Result
For me to be able to choose which projects appear and do not appear in my gitlab dashboard.
Thanks in advance for any help available!
EDIT
I found out that I can star and un-star projects, and that will count as activity on the project without actually changing anything. As the dashboard displays projects by when there was last activity on them then you can actually arrange your project by staring and un-staring the projects in the reverse order you want them to appear.
This somewhat does what I want, but with an ugly work around. Also it will always display 10 projects as far as I can tell, so if I want to only showcase 6 of them the best I can do is push the 4 I don't want to the bottom, but I still can't hide them completely.
This is why I am not writing this as an answer to my question. There has to be a way to just tell a project to be hidden or arrange the projects without this ugly workaround, and if there truly by design isn't a way of doing this then it will also just be good to be officially told that.
GitLab Groups do exactly what you need. See here for more info.
You can assign each project to a different group
You can move a project from one group to another as needed
You can assign different permissions and visibility for each group
You can also create subgroups
Each group/subgroup is treated as a separate namespace, meaning you access it using a different URL
So you can define a public group called yourfullname and a public subgroup called portfolio. Move the projects you want prospective employers to view to the portfolio subgroup and make sure their visibility is also public. All other groups/subgroups should be private. Then people can access your projects by visiting the following URL:
gitlab.com/yourfullname/portfolio
You can still view all of your projects in a single dashboard if you want, or you can view all projects within a group or sub-group by navigating to the desired group URL or dashboard. In the image below, archive and development are private (see the lock icon), but portfolio is public:
Related
I have found recently that a couple of newly created customisation projects seem to have disappeared from the Publish Customisation screen. I was wanting to make a change to one of them but I couldn't find the project anywhere.
On the login screen, I can see which customisations are published, including the two projects that have disappeared, which I have highlighted. The changes in those projects are still working, which is great, but if something was to go wrong or I needed to change the functionality, then I wouldn't be able to find it.
Here is the login screen with the publish projects highlighted.
And here is the publish customisation screen which is sorted by all published customisations. As you can see, the two highlighted projects are missing.
Do you know if there is a reason why they would be hidden, and if there is a way to make them appear in this screen again?
Thanks for any assistance on this.
As Joshua mentioned, the instance has multiple tenants, so I just needed to make sure that I published my customisation to all tenants.
I have this workgroup and I would like to make lists of interesting projects/repos contained in different subgroups. This would make it easier for us to find relevant projects.
I know you can share a project with a group if you are the owner of that project but can I, as maintainer of a group, add links to public projects without the owner of that project having to do anything?
Another option for me could be to just do a readme file with links but then I could get dead links and I would miss the project description and most importantly, when they last was updated.
This does not 100% qualifies as an answer, as i see it as a hack or misuse of a feature of GitLab. But i thought the idea is worth sharing. Additionally it will only work with projects which you can actively change - else this would need interaction of project maintainer.
GitLab supports optional topics on projects, they can be maintained by maintainers within the general settings of a project.
If you add a topic interesting. they get searchable by this tag like https://gitlab.com/explore/projects?tag=interesting
This way, you can create and maintain a list, which is always up to date and show the most recent description, name, etc. - also in connection with permissions (you will not see something you are not suppose to see).
The downside is, that this topic might not be suitable to be (ab-)used within your group, and it might add more confusion for others than it should, because you will see this topic in the project overview page.
I am about to develop one liferay projects and have some query regarding that as follows..
should we create a different portlet project per section or we should combine all section in single portlet project?
we have a different section like "Campaign","Advertise" etc now each section is interconnected,
i mean to say in i would be able to display list of advertise mapped with particular portlet. can please guide me?
I think by section you mean Categories in the Add more section that appears in the dockbar at top-left corner of the portal page.
It is not mandatory to create different portlet projects that go in different categories. It is purely your choice keeping in mind future management.
Following are some considerations to keep all the portlets in one project:
If the portlets are going to use each others services
The portlets will depend on each other for showing the same or similar data, like take for eg: Documents & Media portlet and Documents & Media display portlet would go in one project.
I would say to keep in mind the Software Design Principle of Cohesion and Loose coupling.
This is what I can think at the moment. Hope this helps you in taking your own decision.
Try and put all Portlets under one Project. So that deploy is easy because basically the config files (like, liferay-portlet.tld, liferay-portlet-ext.tld) will be same.
You might wanna make different projects for code that's not about portlets.
I mean different project for Theme, or UI class, different one under Services/Server Side Java code, different for database config/connections etc.
All portlets could go under one project for above mentioned reason.
And you can still have separate space / loose coupling inside this one big portlet project because your (javascript/whichever tech you're using) code will be in separate folders.
About your question of displaying a particular list inside of the portlet, I guess it depends on how you want to code inside that portlet to show your list.
I agree with Prakash K.
Moreover, you should need to have two portlets in the same project (and with "project", I hear "war") if you need to share private portletsessions. So, as Prakash said, if you need interactions between 2 portlets, use one single project.
You can find more information about this particular point in this great blog (not mine): Liferay session sharing demystified
How can I customize share point portal and do it in a way that is easy to create and maintain. Below is a sample of the portal I inherited from someone else who was using images all over. I outlined in red each image. This image method introduces a lot of rigidity and loads of manual labor to make updates and changes.
can this be done using CSS or somethign other than images?
I tried using this site but i think it falls short and only allows customization of basic share point objects.
As a bonus i would like to see if its possible for each portal in the group that represents a particular project pull project related details like "milestones" from a SQL driven project management system we had home grown. Our team has about 25 projects at any given time.
For SharePoint Branding questions then Heather Solomon's blog is the first place to go to.
Especially have a look at the Resources on the right such as the CSS reference
I was thinking of having a tree structure with every team at the top and then having all projects underneath the teams. Something like this:
sharepoint/team1
sharepoint/team1/project1
sharepoint/team1/project1/sub-project
sharepoint/team1/project2
sharepoint/team2
sharepoint/team2/project1
sharepoint/team2/project2
sharepoint/team3
Team1 team2 team3
project1 | project2 project1|project2
sub-project
The problem with this structure is that we are having some few projects that are between several teams.
How do you think that I should structure it?
I would have a totally separate 'Projects' tree (possibly even a site collection), and just link to each project as needed (possibly with a 'members' list on the front page of each project to show who is associated with the project). That way, if the project changes teams you won't have to reshuffle the site hierarchy.
You do not need a separate site collection for this. Just create separate Team Sites for each project and create a SharePoint group (will contain members from different teams) and assign it to each "project" site. Now you can create security-trimmed menus out of the box.
It is very common to want both project and team sites. However, the desire doesn't always make sense so it's best to so some due diligence with your audience/s.
Assuming both sets of sites make sense, I second Moo's advice: use a separate "tree" of sites for each. If performance, scale or ease of administration is a concern these can be places in separate site collections (and SQL dbs). However, this is not necessary per se.
Getting the site collection structure "correct" up front is less of a concern now that the STSADM tool is able to split/combine them after the fact. Also, it's sometimes easier to get it "right" once you see how people are using (or not) the sites.
Good luck!