In the bitbucket interface, there is a toggle that you can click to inherit branching strategies at the top level for a project from the repository's project group settings. I have over 100 of these I need to go through. Is there a call to the REST API that I can make that would set it?
I've been looking for a same solution, but it appears the API doesn't cover this functionality (yet).
I've played around with all manor of API calls/parameters in an attempt to discover the right variable. Even inspecting the payload from the web UI but sadly no luck. I think we're just gonna have to wait.. that or loop through each repo and apply the same configuration.
There is currently a side effect when using this API endpoint. If the repository is inheriting branching model settings from its project, updating the branching model for this repository will disable the project setting inheritance.
We have deprecated this side effect and will remove it on 1 August 2022.
https://developer.atlassian.com/cloud/bitbucket/rest/api-group-branching-model/#api-repositories-workspace-repo-slug-branching-model-settings-put
Related
I have recently started learning about Alfresco Content Service.
I have some questions:
My understanding is that the standard way to add customization is to create AMP's.
Why create an amps for each customization instead of adding it directly to the configurations of ACS? Are there some benefits like not having to restart the service or something?
If apply_amps adds all custom amps to the alfresco server (.war files), won't there be a risk of customizations writing over each other?
E.g if two different amps change the same standard button in the share service.
I have found that there are 2 ways to add these customizations as well:
Add dependency to the pom file. (works only for .jar)
Actually compile the .amp and move it to the correct folder and run apply_amps.sh.
From the documentation it seems to my like AMP-files used to be the standard way of adding customization but that there have now been a move away from this in favor of using regular jar files and eventually in 7.1 and forward use JSON instead.
Yet other tutorials I find mentions things like "always use .amp". Which then seems strange if it contradicts the information on the official documentation.
Also I found something about adding amps through the share interface? Or must they always be added when building the server (.war)?
Could someone provide me with a thorough explanation of the best practice for applying customizations to the alfresco content service? Preferably with details regarding a live production setting.
Thanks for helping me make some of this clearer.
I'll try to give you helpful answers:
Making app packages (APMs or JARs) is much better than changing config manually. It's good for versioning, portability (TEST vs PROD or between projects), composition (you can add some addons witch are often very useful)... It is standard and good way how to build a web app.
About conflict of customizations, I'm not sure how it works. Is good practise always use own namespace for every AMP.
If AMPs write to the same file, result is always append (share-config-custom.xml can get be very big).
Problem about JARs and AMPs is simple. Old version of Alfresco supports more AMPs than JARs. Now it does not matter with way you use. Try to look inside these packages they look very similarly.
I never heard about adding AMPs through the share interface. Have you some source? Only thing which is similar is creating content model through Model manager (https://docs.alfresco.com/content-services/latest/tutorial/model/)
I use for PROD combination of AMPs and JARs. I have a lot of legacy code and addons in AMPs and new things in JARs. Alfresco work with them same...
Problem statement: I have a web page which has widgets on top of it (basically these are injected using JavaScript into the web application). I would like to know if we can find any accessibility violations (WCAG 2.0) in my widgets.
Most of the tools available in the market are capable of scanning through the browser content and give a report of the violations as per WCAG 2.0 (A, AA, AAA).
So I'm specifically looking for a tool which can tell me the violations happening in widgets which are actually not part of web page itself. They are injected into the web application through JavaScript injection.
I would recommend using the Wave tool:
https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh
The widget should still be able to capture errors if something is inject to the website since the wave tool only triggers the scan once you initiate it.
If it's an iframe, you can possibly visit the iframe link directly and run the wave tool on the iframe URL page.
However, please note that it is a tool so it can still fail or show some false positives. Manual auditing for accessibility is always recommended.
There is a plugin called Axe - Web Accessibility Testing for Google Chrome.
You can run the audit at any particular point, so as long as you run it after the widgets have initialised it will work.
If you experience issues testing with this tool then there is something actually preventing those widgets being accessed in the first place as I have used this for numerous projects with dynamically loaded content without issue.
To test API using Postman what should be the best practice for test management.
We tried to create a fork for the folder in collection where developer created his APIs.
But if the developer do any changes on his collection no change will get reflected in our forked folder.
Please advise
After forking a collection, the parent collection may be updated by others. If that happens, your fork will no longer be the same as the parent. In such circumstances, Postman notifies you about this change and allows you to pull these changes.
Read: https://learning.getpostman.com/docs/postman/collections/version-control-for-collections/
My Django project's team is looking to have the designer's CSS in a central place, preferably on the production server (so that there's one "truth" to the current design, a model he claims that he's worked with in the past). Assuming that this is even a good practice, it would mean setting up Git to deploy the CSS in a Continuous Integration (CI) manner to production.
However, I would want to restrict Git somehow for the designer so that he doesn't accidentally update any files other than CSS or HTML. Python and Django files would be updated by developers, who would be deploying in a more traditional manner: working in their own branches and only having a human build manager
merging everything in to master when tested and ready.
Part of the reason that we want the designer to be able to deploy the CSS to a server is to avoid setting up the Django site locally on his laptop (he's not so technical outside of CSS, HTML, and Git).
Is this setup even a good idea? If not, what's the proper alternative?
Assuming that we set up a CI config off of the master branch, and allow the CSS to be pushed to master, can I even restrict the designer's ability to modify and check in non-CSS/HTML files? If so, how?
Is this setup even a good idea? If not, what's the proper alternative?
I have some reservations. It sounds like your designer is going to be the only person pushing changes to production without any gates: no code review, no tests, etc. Continuous integration is great, but a sane process includes safeties that prevent bad deploys. Since the rest of the team is following a different process, you'll end up managing two different pipelines. That's a waste of effort, and inevitably one of them (probably the designer's) falls apart due to lack of attention.
The alternative is put everyone on the same process. Teach the designer how to run the application locally, or build a harness that makes it easier. Unless your site is entirely static, how can they even see what their changes look like without that? Maybe it's more work to train them up, but it's an excellent opportunity for personal growth.
Assuming that we set up a CI config off of the master branch, and allow the CSS to be pushed to master, can I even restrict the designer's ability to modify and check in non-CSS/HTML files? If so, how?
If you go this route, you can use Git hooks to restrict what the designer is allowed to commit. You can either put a pre-commit hook on their client or, if you control the server, a pre-receive hook that runs for only the designer's user. Either one can look at the committed files and block the commit/push if any are not CSS or HTML. There's a pre-commit framework called Overcommit that might be helpful to you. If you're using a code review tool, most have places you can hook in a bot to leave a comment or block the merge when they've modified a file they shouldn't have.
Another option here is trust your coworker. Presumably they were hired because they're effective and useful, so you can save a lot of effort building up restrictions if instead everyone's clear on what they're supposed to be doing and generally doesn't screw it up.
We were checking the feasibility of using Phabricator in our software development activities.
We are currently using JIRA and is looking for a lighter replacement. We feel JIRA as a generic tool that doesn't only focus on software development and Phabricator for us looks lighter and well integrated.
One feature we couldn't find is Work logging. Currently we are using jira work logging feature for extracting data for project management reporting.
So basically my query is
Is work logging feature available in Phabricator ?
Would it be possible to extend the Phabricator for this purpose ?
Technically, yes, there is a work logging feature called Phrequent. It is one of the prototype applications in Phabricator (prototypes must be turned on from Config).
However, it has a lot of missing features. While individuals can start and stop work time on tasks, they cannot edit or delete time entries, and the reporting features are less than ideal (you can only view by person, not by time range or task). More features are planned, though they appear to be low priority right now for the core development team.